java - Spring - Do all beans get processed? -
i have beans.xml file ldap application writing. allowing user choice of several ldapcontextsource(s). each 1 have 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 1 of these context source beans gets instantiated, because 1 referred ldaptemplate bean. however, when run application, spring log messages in stdout provide information each context source, though 1 depended on.
jan 25, 2011 11:56:36 org.springframework.ldap.core.support.abstractcontextsource afterpropertiesset info: property 'userdn' not set - anonymous context used read-write operations jan 25, 2011 11:56:37 org.springframework.ldap.core.support.abstractcontextsource afterpropertiesset info: property 'userdn' not set - anonymous context used read-write operations jan 25, 2011 11:56:37 org.springframework.ldap.core.support.abstractcontextsource afterpropertiesset info: property 'userdn' not set - anonymous context used read-write operations
my questions are:
(1) spring doing context sources not referred / depended on? should never instantiated in application, , worries me spring providing log information each of these beans.
(2) should comment out context source beans not used in application? consequences of leaving them uncommented? standard practice?
thanks,
ktm
maybe check out lazy loading of beans. here relevant explanation spring 2.5.x docs...
the default behavior applicationcontext implementations eagerly pre-instantiate singleton beans @ startup. pre-instantiation means applicationcontext eagerly create , configure of singleton beans part of initialization process. thing, because means errors in configuration or in surrounding environment discovered (as opposed possibly hours or days down line).
however, there times when behavior not wanted. if not want singleton bean pre-instantiated when using applicationcontext, can selectively control marking bean definition lazy-initialized. lazily-initialized bean indicates ioc container whether or not bean instance should created @ startup or when first requested.
for sake of completness here example...
<bean id="contextsource1" class="xxx.ldapcontextsource" lazy-init="true"/>
Comments
Post a Comment