Question

I have a beans.xml file for an LDAP application that I am writing. I am allowing the user the choice of several LdapContextSource(s). For each one I have a different bean, e.g.

<bean id="ldapTemplate" class="yyy.LdapTemplate">
      <constructor-arg ref="contextSource1" />
</bean>
<bean id="contextSource1" class="xxx.LdapContextSource">
      ...
</bean>
<bean id="contextSource2" class="xxx.LdapContextSource">
      ...
</bean>
<bean id="contextSource3" class="xxx.LdapContextSource">
      ...
</bean>

You can see that only one of these context source beans gets instantiated, because only one is referred to by the ldapTemplate bean. However, when I run my application, my Spring log messages in stdout provide information about each context source, even though only one is depended on.

Jan 25, 2011 11:56:36 AM org.springframework.ldap.core.support.AbstractContextSource afterPropertiesSet
INFO: Property ‘userDn’ not set – anonymous context will be used for read-write operations
Jan 25, 2011 11:56:37 AM org.springframework.ldap.core.support.AbstractContextSource afterPropertiesSet
INFO: Property ‘userDn’ not set – anonymous context will be used for read-write operations
Jan 25, 2011 11:56:37 AM org.springframework.ldap.core.support.AbstractContextSource afterPropertiesSet
INFO: Property ‘userDn’ not set – anonymous context will be used for read-write operations

My questions are:

(1) What is Spring doing with the context sources that are not referred to / depended on? They should never be instantiated in my application, and it worries me that Spring is providing log information for each of these beans.

(2) Should I comment out the context source beans that are not used in the application? What are the consequences of leaving them uncommented? What is the standard practice?

Thanks,
ktm

Answer 1

Maybe you could check out Lazy Loading of Beans. Here is the relevant explanation from the Spring 2.5.x docs…

The default behavior for
ApplicationContext implementations is
to eagerly pre-instantiate all
singleton beans at startup.
Pre-instantiation means that an
ApplicationContext will eagerly create
and configure all of its singleton
beans as part of its initialization
process. Generally this is a good
thing, because it means that any
errors in the configuration or in the
surrounding environment will be
discovered immediately (as opposed to
possibly hours or even days down the
line).

However, there are times when this
behavior is not what is wanted. If you
do not want a singleton bean to be
pre-instantiated when using an
ApplicationContext, you can
selectively control this by marking a
bean definition as lazy-initialized. A
lazily-initialized bean indicates to
the IoC container whether or not a
bean instance should be created at
startup or when it is first requested.

For the sake of completness here is an example…

<bean id="contextSource1" class="xxx.LdapContextSource" lazy-init="true"/>