Question

I’m working on a project which means customising an existing application (JasperServer 3.7.1) which is implemented in Spring 2.5.6 (plus a host of other Spring frameworks).

The application consists of a host of applicationContext*.xml containing the bean definitions which when wired together by Spring bring the app to life – I think it’s a typical Spring app configuration as although it my first experience using Spring, it seems all quite well put together and follows a lot of the examples I have seen on the web and in books..

Because I’m actually modifying an existing application, changing beans like filterChainProxy (because we have our own security model ,for example) I’m wary of changing the actual config files that come with the product – instead, where possible, I’d prefer to add extra appContext config files to the existing ones which override existing beans (ie leave the original config in tact, as much as possible).

This I’ve managed to do by creating beans implementing BeanFactoryPostProcessor which on pre-bean initialisation allow me to change the existing property values/bean references to custom ones. This all seems to be working fine.

My query is, say I had a bean with a property that referred to another bean, and my overrider bean changed that reference to my own version of bean, will Spring still instantiate the bean that is no longer referred to ? The reason for asking obviously is that some of these unused beans may be taking up resources, which may be an unwanted overhead.

Thanks in advance

Answer 1

I’m not sure I follow your example, but it might help to clarify a few things.

Generally, Spring will instantiate a bean for every non-abstract bean definition in the context (this is ignoring things like non-singleton bean scopes, but I’ll ignore that for the purposes of this explanation). If multiple bean definition files are used, and some bean names are duplicated, then some definitions will be overridden by others. so far, so good, this seems to be what you wanted.

Once the bean definitions have been established, and any duplicated dealt with, then Spring will then instantiate a bean for each of those definitions. If you have changed the definition of BeanA so that it no longer refers to BeanB, but instead refers to BeanC, but the definition of BeanB still exists, then BeanB will still be instantiated, even if it’s not being used.

If that example is not representative of your question, then please elaborate.