Announcement Announcement Module
No announcement yet.
Obtaining ApplicationContext for web and batch apps Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Obtaining ApplicationContext for web and batch apps

    I am trying to invert control in some lower level code that is common to both our web and batch applications. Therefore, I want to access an the ApplicationContext without knowing how it was loaded. All of the examples I have seen so far show it being loaded directly from a file or as part of the web context.

    Is there a way to access the loaded ApplicationContext in a generic way so code that knows nothing about how the ApplicationContext got loaded can access the beans?

    Or am I missing something that allows Spring to inject implementations into lower level code when the ApplicationContext is loaded?



  • #2
    I realize people don't like being answered "why do you want this?" when they are really asking "how do I do this?", but still -- is it applicable in your case that the lower level code is injected with its dependecies directly, rather than having to obtain the application context itself to begin with?


    • #3

      The low level code I am implementing is a set of dynamic and typesafe codes/enumerations. The application needs to determine by configuration if the codes are read from a database, remote method, or file. That low level code should not care if it is called from the context of a web application or batch Java program.

      Without a way to lookup a loaded ApplicationContext, I only see the following options for using Spring at lower levels of code.

      1. Pass the ApplicationContext through multiple levels of method calls. This is not very appealing since many levels may have no need of the ApplicationContext.

      2. Initialize the ApplicationContext in the lower level code. This code should only know the name of the service bean and not the configuration file name or its location.

      3. Write my own context provider class that allows both types of applications to register their ApplicationContext. I am not sure I like this because it seems to be circumventing access of the context from the core framework.

      I feel sure that I must be missing something or that I trying to do this in the wrong way.

      Thanks. for the response.


      • #4
        Where I was going is actually this - I have rarely seen a scenario where some typical business logic code has to obtain a reference to the app context, because there is almost always some way to inject into the code the dependencies rather than having to have the code explicitly obtaining the app context and looking up the dependencies by itself.

        Anyway, if you have to get hold of the application context, check out and see if org.springframework.context.access.ContextSingleto nBeanFactoryLocator suits your needs.


        • #5
          Initiating dependency injection

          From what I can understand dependencies do not get injected until getBean() is called on some BeanFactory. If you are working wihtin frameworks already wired together by Spring such as Spring MVC or ORM, it seems to handle the messy details of getting the BeanFactory and initializing the beans.

          If I am interpreting this correctly, then frameworks within an organization must also initiate the process of injecting dependencies by getting a bean from a BeanFactory. That is, unless they have the luxury of being coced at a level where they can depend on on of the other Spring packages to provide the BeanFactory for them.

          Thanks for the pointer to the org.springframework.context.access.ContextSingleto nBeanFactoryLocator class.

          Thanks for your help. If I am completely misunderstanding how things work, please let me know.



          • #6
            No, singleton beans are normally created in the application context constructor. Take a look at ClassPathXmlApplicationContext(String[] configLocations) and the refresh() method it invokes.


            • #7
              Barring the fact that my requirements might be different and that I've just started with spring, I have the same question.

              The problem with ClassPathXmlApplicationContext (and others) is that it needs a file to get started.

              Deep in the bowels of my code, I want to access a bean defined via Spring, but in order to do so I must point the ClassPathXmlApplicationContext to my config file. In order to have "reusable" code, I do not want to code the file in this method.

              Is there a better way to do the following somewhere deep in the bowels of my code

              ClassPathXmlApplicationContext springCtx=new ClassPathXmlApplicationContext( "spring.xml");
              MyBean bean= (MyBean)springCtx.getBean( "myBean");

              In other words, deep in the bowels of my code I want access to the "MyBean" singleton, but in order to get hold of it, it seems I must specify a filename. I would like to get hold of this singleton without specifying the filename (in this part of the code)

              PS. This is not a J2EE app, but a standalone swing app


              • #8
                The application context is usually loaded once, in one place - at your application entry point. For your swing application that would be your main method and for web applications ContextLoaderListener.


                • #9
                  Ok, so I load it in the "main" of the swing app, but how does the other code get hold of this context ?


                  • #10
                    See if org.springframework.context.access.ContextSingleto nBeanFactoryLocator works for you.

                    (but then, again, whenver you feel like in your code deeply somewhere you need to "get hold of the context", you probably want to rethink your design and see if there is a way to "inject" the bean rather than to "get" it - usually there is.)


                    • #11
                      There are many different strategies you can use - ContextSingletonBeanFactoryLocator is one, other then that you can pass context around as a parameter, you can ryo a singleton that will hold a context for you, you can let spring handle your windows instance creation. Actually anything but loading a context everytime you need it will work