Tuesday, December 21, 2004

Datasources selection with Spring

The aim is to permit to an application (and the user) to select a specific datasource to use, so a user can choose a specific database and datas to access. We can use the same mechanism than Acegi: a filter to get the datasource name and place it in known holder ( based on a thread local ) and a specific datasource ( proxy on datasources ) to get this name in order to select the datasource to use.

- Datasource name context: it's in fact a class to store the name of the DataSource et a class (a simple ThreadLocal) to hold it (the known place).
Here is an example of these two classes and interfaces:

public class DataSourceContextHolder {
private static ThreadLocal contextHolder = new ThreadLocal();

public static void setContext(DataSourceContext context) {

public static DataSourceContext getContext() {
return (DataSourceContext) contextHolder.get();

public interface DataSourceContext {
public void setId(String id);
public String getId();

public class DataSourceContextImpl implements DataSourceContext {
private String id;

public void setId(String id) {

public String getId() {
return id;

- Filter to detect context: the filter look for an datasource id in the session and put it in the context holder. The filter might be enhanced to have the feature to select the id and block this change when a user is authenticated on a database.

- Datasource selector: thanks to Spring, there is a datasource abstraction so we can put a proxy between our datasource and application. Our datasource proxy could select another datasource configure in Spring at runtime using the datasource context.
Here is an example of this proxy:

public class DataSourceSelector extends AbstractDataSource
implements BeanFactoryAware {
private BeanFactory beanFactory;

public void setBeanFactory(BeanFactory beanFactory)
throws BeansException {

public Connection getConnection() throws SQLException {
DataSourceContext context=DataSourceContextHolder.getContext();
DataSource datasource=(DataSource)beanFactory.getBean(
return datasource.getConnection();

public Connection getConnection(String login,String password)
throws SQLException {
DataSourceContext context=DataSourceContextHolder.getContext();
DataSource datasource=(DataSource)beanFactory.getBean(
return datasource.getConnection(arg0,arg1);

This mechanism is independant of the application (Spring offers this
facility!) but we must be carefull to not permit to access a database
without be authenticated. The order of filter (with use of security filter such Acegi's) could be dangerous... The solution is not to permit to switch from
a datasource to another when a user is authenticated.

Monday, December 13, 2004

Spring and ORM

Spring integrates several ORM at this time:

  • Hibernate
    See the following link for more informations:
    Spring reference documentation
    Hibernate site

  • JDO
    See the following link for informations about Spring and JPox ( a free JDO implementation ):
    JPox 1.1 documentation
    See the following link for informations about Spring and KODO ( another JDO implementation ):

  • OJB
    Spring javadocs
    Examples: see the PetClinic sample application in the Spring distribution!
    Threads on the subject:
    Spring adds support for ojb
    Announce of support added

  • TopLink
    See the following link for informations about Spring and TopLink:
    Spring / TopLink on Oracle site

    Spring offers now a perfect integration of tools for J2EE architecture to access datas of relationnal databases.
  • Sunday, December 12, 2004

    JCA and Spring

    At the moment, Spring doesn't offer support for JCA ( Java Connector Architecture ). A support of JCA can be helpful in order to hide the use of CCI ( Common Client Interface ) API, to integrate with the IoC container of Spring and to use the AOP framework. The aim is offer facilities to use it:

  • Configuration of ConnectionFactory in a managed ( get from JNDI ) and in a non-managed mode ( configure as a bean )

  • Conversion from Record to Object / Object to Record

  • Declarative of transaction configuration ( local and global transactions ) with interceptors

  • Use of CCI with template and objects

  • The idea is then to extend the framework to different EIS to integrate them easier in J2EE applications. For example, with CICS, communications are based on a COMMAREA ( table of bytes ), so it could provide classes to work on table of bytes instead of Record and a data mapper to transform object to COMMAREA / COMMAREA to object.