lazy-init problem

[ctassoni]

I set lazy-init as the default for beans in my core applicationContext. This works when I run the app in stand-alone mode, but when I run it as a webapp I find that Spring is eagerly instantiating beans and injecting colloborators into them.

A quick look in the debuger shows that FilterToBeanProxy is causing the instantiations. FilterToBeanProxy is, of course, declared in web.xml, and is thus not invoked when I run the app as a stand-alone.

So how can I prevent FilterToBeanProxy from eagerly instantiating beans from my core applicationContext? By the way, the app is using version acegi version 0.82. I have a small preference not to upgrade immediately, but will be glad to do so if that's the only way to solve this problem.

[Ben Alex]

Why is this a problem? Is FilterToBeanProxy eagerly initializing something that is expensive to initialize? Generally I use (and see other projects using) the default eager initialization without a problem.

[ctassoni]

Yes, SessionFactories and DataSources are being initialized, and these are expensive. In this particular case, the expense is not so much in startup time (that's about 5 seconds or so) but in developer productivity. All (two) of our developers sometimes work off site, and very often work on features that don't need to hit the database, but that are instead using mock DAOs. Running with the FilterChainProxy means that we still need to have a database running locally because the SessionFactories and DataSources are being eagerly initialized.

In fact, the cost in development time is not restricted only to the inital effort of installing Oracle locally and importing a database dump. Even though we're running with mock DAOs, we frequently need to re-import a new version of the database dump so that the newly revised SessionFactory doesn't blow up because it doesn't find the expected changes in the newly revised database. Either that, or we just remove the filterChainProxy declaration from web-xml. But that's not always practical.

I'd also like, in the near future, to use lazy initialization to declare several data sources, and only use those that are resolved by a PropertyPlaceholderConfigurer. In short, I think lazy initialization is a very valuable feature.

[Ben Alex]

FilterToBeanProxy and the associated FilterChainProxy both use the Service Locator pattern to obtain (by name) only the beans they require. Therefore I'm not sure why it would be causing an eager initialization of all of your beans. Are you sure it's not another bean responsible?

[ctassoni]

I remember debugging the problem and, at that time, being convinced that FilterToBeanProxy was the cause. But I may have missed something. I didn't do much more than note that lazy-init works when I deploy in standalone mode, doesn't work when deploying as a webapp, and that the debugger finds bean initialization initiated by FilterToBeanProxy.

It might be that I could refactor so that the beans that FilterToBeanProxy requires don't cause so much overhead. But if it happens that 1) some of those beans need datasources, and 2) FilterToBeanProxy locates the beans it needs eagerly, then refactoring won't help much.

I guess I should ask, does FilterToBeanProxy locate the beans it needs eagerly? And if so, is there a way to configure it so that it acquires those beans lazily.

[Ben Alex]

You could look into the FilterToBeanProxy servlet-container-managed parameter, but I don't think you'll achieve much as the initialization will be deferred, at best, until your first web request comes in when all the filters will need to fire.