Announcement Announcement Module
No announcement yet.
initializing singleton order Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • initializing singleton order

    Hello there!

    In my application there is singleton which holds configuration parameters for entire application. For this singleton there is set of DAO objects (only one instance of DAO is available in the system during lifetime, so each time configuration could be loaded from XML file, database or whatever), and I need to call it's method "load" once application starts up, to guarantee all configuration parameters will be loaded BEFORE any other bean would be instantiated and wired.

    So I need to

    1) instantiate singleton object with configuration
    2) instantiate DAO object for this configuration singleton
    3) call load method of the DAO object
    4) process the rest of initializations etc

    How do I do this with Spring?

  • #2
    First off, there is no need to make classes Singletons yourself; let Spring take care of that for you.

    B. Create bean defs for the various DAOs and use the 'init-method' attribute to call load().

    Thirdly, create a bean def for the configuration object and use the 'depends-on' attribute to depend on the DAO bean defs.

    Finally, have all your other bean defs depend on the configuration object bean def.

    Give that a shot.


    • #3
      Well, I don't like to specify all beans to be depending of this bean, it could be a lot of extra XML code. May be I can reduce amount of XML lines by providing some abstract bean definition which depends of the configuration bean, but this could be a point where errors will appear if somebody of the team will add some bean definition which is't inherited from that abstract bean definition.

      Is there any other way to force Spring instantiate some beans first, may be if I define them first in the XML file - that would work?


      • #4
        I did not say I liked the suggestion; it was simply a solution to your stated requirements. As for the actual implementation of it, yes, an abstract bean def would be the way to go...

        However, now that I think about it a bit, as long as the configuration obejct is being injected with Spring, you shouldn't have to worry about order. The first time it is needed, Spring will create it and call its init method before injecting it. So, it won't matter who uses it first; the first use will cause it to be initialized for all later users.


        • #5
          Parent application context?

          I have used parent application contexts to insulate bean definitions from each other, and I find that to be quite convenient. You can normally guarantee that all beans in the parent context are fully initialised before anything happens in the child. The support for parent contexts is pretty mixed, and a little opaque, so the solution to your problem might depend on the way you normally instantiate the bean factory.

          If you are using Spring MVC then you already have a parent-child relation between the main application context and the one for your Controller. There is also some support in ContextLoader for a parent context to the main web app context. For anything more complicated than that you might have to write your own context loader, e.g. based on SingletonBeanFactoryLocator.