Eager singleton init not so eager?

[daleth]

I'm sure I'm missing something painfully obvious here but so far I haven't stumbled upon it.

I've written a very simple bean that configures another library's configuration singleton via the information injected into my bean. This simple configuration bean is using the default scope (singleton) with the default lazy-init (false) settings and implements InitializingBean. I've also not changed the /beans[@default-lazy-init], from false. The logic to configure the other library's singleton is within the afterPropertiesSet() method.

From my reading of section 3.3.5, in the spring documentation,

The default behavior for ApplicationContext implementations is to eagerly pre-instantiate all singleton beans at startup.

I expected that as soon as the configuration files were loaded into the app context (and all the bean definitions created) the configuration bean would be instantiated and run, configuring the lower-level library. That's not what happened. I can cause the bean to be initialized by specifically asking the context for it, but that's not what I'm after. Is there a way to have the bean created immediately upon loading up the context?

Env:
Spring 2.0.4
Sun JRE 1.5.0_07
Mac OS X 10.4.9

Thanks!

[karldmoore]

How are you loading the ApplicationContext? Is it possible to see this code and configuration?

[daleth]

Sure, all I'm doing is creating a Generic app context and using an XmlBeanDefinitionReader to load a set of Resources. Here's my util method that takes a bean registry and loads it up with a set of confgs. I'll note that the Resource objects passed in as an argument are not Spring's org.springframework.core.io.Resource objects but are very similar.

public static void populateRegistry(BeanDefinitionRegistry beanRegistry, List<Resource> configurationResources)
            throws ResourceException {
        XmlBeanDefinitionReader configReader = new XmlBeanDefinitionReader(beanRegistry);
        configReader.setValidationMode(XmlBeanDefinitionReader.VALIDATION_XSD);
        configReader.setDocumentLoader(new SpringDocumentLoader());

        int numOfResources = configurationResources.size();
        org.springframework.core.io.Resource[] configSources = new org.springframework.core.io.Resource[numOfResources];
        for (int i = 0; i < numOfResources; i++) {
            configSources[i] = new InputStreamResource(configurationResources.get(i).getInputStream());
        }

        try {
            configReader.loadBeanDefinitions(configSources);
        } catch (BeanDefinitionStoreException e) {
            throw new ResourceException("Unable to load Spring bean registry with configuration resources", e);
        }
    }

And my code that calls the above method is just:

GenericApplicationContext gContext = new GenericApplicationContext();
SpringConfigurationUtils.populateRegistry(gContext, configs);

And the Spring config for my configuration bean is (I explicitly set the lazy-init method simply to be sure that the documented default wasn't incorrect):

<!-- Spring configuration file that boostraps OpenSAML -->
    <bean id="shibboleth.OpensamlConfig" class="edu.internet2.middleware.shibboleth.common.config.OpensamlConfigBean" lazy-init="false">
        <constructor-arg>
            <list>
               <!-- snip... List o' config strings -->
            </list>
        </constructor-arg>
    </bean>

[Dave Syer]

You probably still need to call refresh() on your application context to get it to run all the lifecycle stuff. The default behaviour that you read about applies only to the constructor-based context creation strategies; it does not include building a bean factory by hand in the way you have done it.

[daleth]

Thanks David, that was it.