Announcement Announcement Module
No announcement yet.
servlet context vs application context Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • servlet context vs application context

    In the spring framework, is it better practice to put the service layer bean definitions in the application context or the servlet? I have always put them in the application context so that I could reference them from many servlets (I realize I could put all service/manager beans in their own servlet and just include that with all other servlets in the web.xml, but I don't love that solution unless that is how Spring intends us to do it).
    It has become a problem now, because I am using my company's spring framework "framework" (parent DOM, incorporating them as maven dependencies), and they define things like "sessionManager" in the servlet. So, when trying to auto-inject these beans into my own managers (that are defined within application context), I clearly get an error because the beans defined in servlet have yet to be created.
    So my question is twofold:
    1. Is it better spring practice to put manager/service layer in application context or servlet?
    2. Is there ANY way to auto-inject a bean (I use annotations) defined in a servlet into a bean defined in the application context?


  • #2
    In general shared objects should go in your root application context, al things only relavant for the servlet should go in the servlets application context.

    YOu cannot inject beans from the child into the parent, the other way around is the only way.


    • #3
      Thank you for your response. So theres no "rule" in spring about managers- they can be defined in application context and servlet contexts according to the spring framework "way", but if they are to be shared put them in application context?



      • #4
        There is no rule, just a rule-of-thumb... You could even put everything in the root context or the servlet. What ever you like...


        • #5
          I have a very similar question. I'm also struggling with where to put all the services beans.
          If I activate the component scan only in the root-context then the dispatcher servlet doesn't see any controllers. Is this a configuration problem on my side or by design?
          If I activate the component scan only in the servlet-context it is harder to access them in filters or tags, which usually run outside the servlet.
          Is here a clear access rule how to get servlet-context outside of the context?
          It is a little bit confusing with the WebApplicationContextUtils.getWebApplicationContex t and RequestContextUtils.getWebApplicationContext methods. For me it is not quite clear which of the contexts you get.

          And then the other thing is, that if I add the component scan in the root-context and in the servlet-context all the beans get instanced twice...

          Do I need a root-context if I only work with one servlet-dispatcher?
          How to access the servlet context outside of the servlet to be sure that it is the servlet context and not the root context (if a root context is added later for example)?
          Does the only solution to this is that I use exclude-filter on the component-scan, which would mean that I exclude all the @Controllers in the root-context und only include them in the servlet-context component-scan?

          Any enlightment is greatly appreciated.


          • #6
            The component-scan by default scans everything, so if you have 2 context you n eed to configure what to scan for.

            The HandlerMappings (and not the dispatcherservlet!!!!) by default look in the context in which they are defined for (@)Controllers. You can configure the HandlerMapping by explicitly configure them and tell them to look in the parent contexts also.

            Basically there are different approaches to get a working example.

            Regarding WebApplicationContextUtils and RequestContextUtils I suggest a read of the java doc, which explains it quite clearly.


            • #7
              Thanks for the quick answer.

              Originally posted by Marten Deinum View Post
              The HandlerMappings (and not the dispatcherservlet!!!!) by default look in the context in which they are defined for (@)Controllers. You can configure the HandlerMapping by explicitly configure them and tell them to look in the parent contexts also.
              By HandlerMapping do you mean "<annotation-driven />"? This is defined in the servlet-context and the doc for this tag states that it only works in the servlet-context. At least this is how I understand this:

              HTML Code:
              Configures the annotation-driven Spring MVC Controller programming model. 
              Note that, with Spring 3.0, this tag works in Servlet MVC only!
              Originally posted by Marten Deinum View Post
              Regarding WebApplicationContextUtils and RequestContextUtils I suggest a read of the java doc, which explains it quite clearly.
              Please let me elaborate on those two classes as I find the docs or maybe the naming a little confusing. Let this base on the Spring Template Project "Spring MVC Project" from STS 2.3.2.
              In this project you have the following web.xml

              HTML Code:
              As I understand from this is that the ContextLoaderListener loads the root-context.xml and the DispatcherServlet loads the servlet-context which uses the root-context as parent.

              Now from my point of view I would call the servlet-context the web-application-context. The docs in the WebApplicationContextUtils.getRequiredWebApplicati onContext suggest that the root-context is the web-application-context:

              HTML Code:
              Find the root WebApplicationContext for this web application, 
              which is typically loaded via ContextLoaderListener
              So technically this method would always return the WebApplicationContext which I would call the root-context since it is loaded from the root-context.xml?

              One more thing which makes it more confusing is that the WebApplicationContext interface extends the ApplicationContext inteface. One would assume that the ApplicationContext interface is the root-context and the WebApplicationContext is the servlet-context. (ok this might be a little bit far fetched)

              The RequestContextUtils class seems to be more related to the DispatcherServlet. From the docs:

              HTML Code:
              Utility class for easy access to request-specific state which 
              has been set by the DispatcherServlet. 
              But the method getWebApplicationContext(ServletRequest request, ServletContext servletContext) would not always return the web-application-context. It might also return the root-context when this method is called from outside the DispatcherServlet:

              HTML Code:
              Look for the WebApplicationContext associated with the 
              DispatcherServlet that has initiated request processing, and for the global 
              context if none was found associated with the current request. This method 
              is useful to allow components outside the framework, such as JSP tag 
              handlers, to access the most specific application context available. 
              Is that right? (I would assume the global context to be the root-context)

              Some side notes:
              1. I have worked with spring for some time now but would like to setup a very clean config for my next project.

              2. I know the naming of the xml files can be chosen but I would expect them to be somehow consistent with the docs.


              • #8
                You are thinking way to complex...

                The root ApplicationContext (regardless of its type) is the one shared by all servlets it has nothing to do with the fact that it is an ApplicationContext, WebApplicationContext or anyother arbitrary ApplicationContext. (I suggest a good book on spring).

                The RequestContextUtils is always returning an applicationcontext, and it looks first in at the dispatcherservlet the current request is mapped to else it delegates to the root (if available).

                basically you are thinking to complex and are making things up which don't really apply.

                Regarding HandlerMapping I suggest a read of the reference guide.
                Last edited by Marten Deinum; Oct 18th, 2010, 08:54 AM.


                • #9
                  Originally posted by Marten Deinum View Post
                  You are thinking way to complex...
                  I guess you are right. I looked at chapter 15. of the docs (again) and now it is more clear to me.

                  I moved the <context:component-scan ... /> and <mvc:annotation-driven /> to the root-context.xml. My servlet-context.xml has now only the view resolver bean and the DispatcherServlet still finds the @Controllers.


                  • #10
                    Well actually, the purist in me, the DispatcherServlet finds the HandlerMapping in the rootcontext instead of the one in the DispatcherServlet. The HandlerMapping finds the correct (@)Controller (the HandlerAdapter is the one executing them and the DispatcherServlet is binding them all together).