Bootstrapping IoC container in Spring standalone app

Hi, I was reading some valuable comment on the Singleton Antipattern in Rod Johnson's "J2EE Development without EJB".
He also mentioned when it can be usefull, e.g. during container bootstrap of a standalone application.

This is exactly what I did in one of my current projects and I'm wondering if I did the right thing or if the antipattern still could be avoided.
It is a Spring project (much like Spring iBATIS JpetStore) and it is standalone, a runner class in the form of an NT service (JavaService by Alexandria) is serving as "bootstrap", but - unfortenately - it is part of a custom library I cannot (or better should not) modify.

Yet I want the application context, bean definitions, etc. initialized only once as default behaviour, so I chose to create the following singleton :

Code:

---

public class SpringFactory {

    private static SpringFactory springFactory;
    private static BeanFactory  beanFactory;


    private SpringFactory() {
    }

    public static SpringFactory getInstance() {

        if (springFactory == null) {
            springFactory = new SpringFactory();
        }

        return springFactory;
    }

    public BeanFactory getBeanFactory() {
        return getBeanFactory(false);
    }

    public BeanFactory getBeanFactory(boolean reload) {

        if (beanFactory == null || reload) {
            loadApplicationContext();
        }

        return beanFactory;
    }

    private void loadApplicationContext() {
        Properties props = PropertyLoader.loadProperties("context");
        String contextConfigLocation = props.getProperty("contextConfigLocation").trim();
        String[] configLocations = contextConfigLocation.split(",");
        ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(configLocations);
        beanFactory = (BeanFactory) appContext;
    }

}

---

A custom propery loader class reads the config locations from a context.properties file (very similar to contextConfigLocation in web.xml in case of a Spring webapp) :

Code:

---

# SPRING CONTEXT
# ==============

contextConfigLocation = applicationContext.xml, dataAccessContext-local.xml, test-beans.xml

---

The rest is obvious, an application would have access to a bean by calling the getBeanFactory() method.

Code:

---

BeanFactory beanFactory = SpringFactory.getInstance().getBeanFactory();
...

---

There is also an issue of context reloadability; if there is only a change in the bean configuration I would not want to restart the whole container, so I forsaw a getBeanFactory(boolean reload) method to handle this.

So, is this a good approach or are there better ways to do it ? I'm very interested in the opinion of you experts :wink:

Kind regards,
M

Using some sort of singleton is a viable strategy for small amounts of glue code. Ultimately, IoC has to get kicked off somewhere...

Your approach looks ok. Note however that Spring includes the BeanFactoryLocator inteface, and a keyed-singleton implementation of it called SingletonBeanFactoryLocator/ContextSingletonBeanFactoryLocator, which is somewhat of a superset of your class.

Thank you Colin for your advice.
I will take a look into the BeanFactoryLocator interface and their implementations.

One thing though, with small amounts of glue code, do you mean a low frequency usage of a singleton or a low quantity of singletons ?
Just that I understand you correctly. I assume the latter.

Regards,
M

I was actually talking about the amount of code that even knows about the context and/or singleton. It's a given that you don't want/need many singletons...

Mordred,

I am very interested in this topic. Can you please provide update? What technique did you decide to use for bootstrapping container?

Thanking you for this.

Sorry for the late answer, I don't always check this forum :shock:

I went for direct usage of the SingletonBeanFactoryLocator, because it's much more mature and better designed then my little SpringFactory :wink:

For example, defining beanFactory contexts in an xml file is much more convenïent then my simple properties file (wich only contained 1 beanFactory), it also allows creating/destroying context definitions at run-time.

But, just to make things clear, I only used that approach because I couldn't bootstrap at startup. Luckily for me, at a later stage, the company that developed the 3rd party bootstrap class changed it to an abstract class, so I could extend it and add Spring bootstrapping 8)

In order to simplify main management, I have created https://jira.springsource.org/browse/SPR-9044. If you like the proposed approach, please vote for it.