Announcement Announcement Module
Collapse
No announcement yet.
Bootstrapping IoC container in Spring standalone app Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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

  • #2
    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.

    Comment


    • #3
      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

      Comment


      • #4
        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...

        Comment


        • #5
          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.

          Comment


          • #6
            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)

            Comment


            • #7
              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.

              Comment

              Working...
              X