BeanNameAutoProxyCreator with a dynamic interceptor list

[sgarlatm]

I would like to supply a dynamic list of TransactionInterceptors to the BeanNameAutoProxyCreator. The reason I’d like to do this is that the application I’m working on accesses a dynamic list of databases that is known only at run time, not at compile time. The databases do not need to participate in distributed transactions. The application functions like some of the tools in the IBM Rational suite: the user chooses which database she would like to use when logging in.

I would like to apply declarative transaction management to each of the databases the system administrator has defined by performing the following actions whenever the application context is loaded or reloaded:
1) Detect the DataSources defined in the application context
2) Create TransactionManagers and TransactionInterceptors for each DataSource and
3) Supply the databases to the BeanNameAutoProxyCreator.

Now for my question: is this a good approach or should I try something different? One problem with my approach is that there doesn’t seem to be a way to supply a dynamic list of interceptors to the BeanNameAutoProxyCreator. In order to do this, the AbstractAutoProxyCreator.resolveInterceptorNames would need to be a protected method rather than a private, as it is currently defined. If this is the only way, I’d be happy to supply a patch.

Thanks in advance for your help!

Matt

PS - has anyone ever considered a WriteableApplicationContext interface that would allow for easy programmatic changes of the application context at runtime?

[Rod Johnson]

has anyone ever considered a WriteableApplicationContext interface that would allow for easy programmatic changes of the application context at runtime?

Have a look at ConfigurableApplicationContext. You can get a ConfigurableListableBeanFactory from it, which may be what you want.

Are you changing singleton instances (which would seem dangerous), or creating new prototypes for each user?

[hucmuc]

In development mode, runtime detection of modifications is mandatory. I've introduced spring at work and 99% of the problem is not AOP or unit testing or the concepts (developers love it). The main problem is getting the configuration right (typos etc). It is a real thorn in our side.

There are so many application context files now. One for the mvc, one for the facade, one for the business layer and one for the dao. Actually each of these are broken down smaller files so we don't have huge files.

Sorry for going on. It is a point of frustration in our team to the point they want to programatically define the beans in Java (just like the pico container).

Dino

[sgarlatm]

I think Rod's point is that the ConfigurableBeanFactory.registerSingleton method allows programmatic addition of singleton beans to a bean factory. This method is available to most application contexts. (If you need to add prototypes, you could always register a singleton org.springframework.beans.factory.ObjectFactory using the convenient org.springframework.beans.factory.config.ObjectFac toryCreatingFactoryBean).

I'm trying this out now, and I'll let you know how it goes With a WriteableBeanFactory I meant a bean factory that knew how to take its runtime contents and serialize that to an XML file.

Matt