Announcement Announcement Module
Collapse
No announcement yet.
Best practice question: bean factory & standalone app Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Best practice question: bean factory & standalone app

    Springers,

    Iím developing a spring-based standalone application, and I was wondering how gurus create their bean factory (or app context) and retrieve the singletons.

    Here is what Iím doing:
    I have a BeanManager class that I instanciate in the main function and that is responsible for creating the bean factory (and reading the config files). This class also keeps a reference to the bean factory.
    The BeanManager class has a getBean method that simply redirects to factory.getBean. Most singletons are autowired to other beans; I only use BeanManager.getBean for the beans I use a bit everywhere (like the bean that contains my application parameters).

    Does it sound right to you, or is there a better, more spring-like, way of handling this?

    Thanks,

    Susie.

  • #2
    It's how I'd do it. Sounds similar to what I do with JUnit tests (an approach copied from Matt Raible's AppFuse). I have an abstract SpringEnabledTestCase that creates a static ApplicationContext and makes it available to my subclassed business service tests. Of course, you could just as easily make it available to non-subclassed objects. You're right to tie the lifecycle of ApplicationContext to your program's main entry (and I assume, exit) point.

    HTH,
    Scott

    Comment


    • #3
      Thanks Scott for your input. So, a Spring application should have one (and only one) old-style singleton, the one that wraps the app context.

      Susie.

      Comment


      • #4
        Yes, just one singleton/factory/locator (what's the politically correct name for it this week?) is all you'll need. BTW I recommend eagerly instantiating the ApplicationContext (versus lazily doing so and flirting with double-checked locking problems or incurring a performance penalty through an instantiation check). Just make your ApplicationContext a static property and instantiate it as classloading time.

        I.e.

        Code:
            private static ApplicationContext ctx = null;
        
            static {
                ctx = new ClassPathXmlApplicationContext(Constants.SPRING_APPLICATION_CONTEXT_CONFIG_FILE);
            }
        Scott

        Comment


        • #5
          There is also something in the factory stuff that allows the container to load in one's own singleton bean on startup?


          http://www.springframework.org/docs/...Bootstrap.html

          quote:
          Code:
          One singleton to rule them all. Reads System properties, which must contain the definition of a bootstrap bean factory using the Properties syntax supported by PropertiesBeanDefinitionReader. The name of the bootstrap factory must be "bootstrapBeanFactory". Thus a typical definition might be: bootstrapBeanFactory.class=com.mycompany.MyBeanFactory 
          
          Use as follows: BeanFactory bf = BeanFactoryBootstrap.getInstance().getBeanFactory();
          Wonder what the use case is for using this rather then the other factories.

          Comment


          • #6
            If you actually have a use-case for BeanFactoryBootstrap, then you are probably better off using one of the singlton variants of BeanFactoryLocator, such as SingletonBeanFactoryLocator...

            Comment


            • #7
              Susie,

              You might want to take a look at how we bootstrap Spring in a standalone environment for a Swing-based rich client application, illustrated by the Spring Rich Client Project Petclinic Sample Application.

              Basically, we have a framework class -- org.springframework.richclient.application.Applica tionLauncher -- responsible for loading the main context for the application; invokable via a simple bootstrap class with a main method. For convenience, we have a "ApplicationServices" service locator object with a static accesor for locating common singleton application services (like those for icon and image loading), typically looking up using the Spring application context (but we obviously favor dependency injection/wiring for most things, as you mentioned.)

              Just curious: when you say standalone - what does the app's interface? command line driven? Swing app? other?

              Keith

              Comment


              • #8
                Keith,


                Originally posted by kdonald
                You might want to take a look at how we bootstrap Spring in a standalone environment for a Swing-based rich client application
                Thanks, I'll have a look. Digging into the RCP was on my todo list.

                Originally posted by kdonald
                Just curious: when you say standalone - what does the app's interface? command line driven? Swing app? other?
                It's a swing app.

                Susie

                Comment

                Working...
                X