I'm using org.springframework.web.servlet.DispatcherServlet and org.springframework.ws.transport.http.MessageDispatcherServlet in the same app but each is loading own application context, I need to load all beans in a single application context.
The application consists of typical layers web>app>dao etc
What I have tried is to use one single spring-root-context.xml by setting it in the contextConfigLocation.
But didn't help, this has been an issue for me for a long time an I would appreciate any help with this.
Any online references would be a great help.
What you need here is the ContextLoaderListener. This is a ServletContextListener which creates a root WebApplicationContext that is shared amongst all servlets in that webapp.
Your DispatcherServlet and MessageDispatcherServlet will still create their own contexts, but each will have the root context as their parent, so they'll both be able to use beans defined in that root context, like DAOs etc. Some beans will have to remain in the servlets own contexts, such as controllers, view resolvers, SOAP endpoints, and so on, but the shared common beans can go in the root.
For an example on how to configure this, see the Spring docs.
Related
I am looking for any ideas or PoC on how to integrate (specifically configure) Spring MVC and Vaadin (Framework 8) in one web application; preferably as a context hierarchy.
The use case is the Vaadin application as the root context "/" and the Spring MVC application on some other context "/m" (which will be used for server mobile-friendly views).
I have not been able to find any examples, partial or fully, that shows how this is achieved in the configuration (Spring Boot) and I'm constantly running into various problems with invalid context loading, unmapped MVC view references etc. depending on the examples I'm running.
I've looked into this from the perspective of this line in the Vaadin documentation, but have simply not found anything on these topics I can combine to make a solution.
It is possible to map both DispatcherServlet and SpringVaadinServlet to different context paths to use both simultaneously to e.g. support Spring MVC and Vaadin in the same application. If doing so, remember to also map the path “/VAADIN/*” to the Vaadin servlet for serving static resources.
I'm reading the spring framework documentation and now I'm at application scope concept. What the documentation says about that concept is this:
This is somewhat similar to a Spring singleton bean but differs in two
important ways: It is a singleton per ServletContext, not per Spring
ApplicationContext
To me, what's unclear is how can we imagine the relationship between Spring application context and Servlet context.
I'd assume that there two possible cases for the relationship between them:
I
II
So, how does the Spring application context relate with Servlet context? Is it case I or case II or neither of them?
It's neither of them.
ServletContext is the standard Java EE application scope. Each deployed webapp has one and only one servlet context.
Inside this webapp, you can have one (typically) or several Spring application contexts: one per Spring-MVC dispatcher servlet.
I am a bit familiar with Spring framework but am still having lots of question concerning use of spring from project architectural view point. Now I am setting up Spring 3 and a Maven web application and am willing to try out all the the fancy component-scan's and autowiring features however this is where I get confused.
I am trying to break the project into sub-modules. And at some point these sub-modules may include something-context.xml in classpath*:resource/META-INF, like for instance when I will want to define a datSource related stuff in a separate module. So that's fine spring let's you load context files from within class-paths of all of the jars.
But here is where it gets vague - say I am using component scan. I am obviously using spring DispatcherServlet and it needs a servlet context to be loaded, and then there is a global application context parameter specified in web.xml contextConfigLocation.
So now servlet context config has a component-scan feature enabled for com.mycom.project.controllers and context loaded in the global contextConfigLocation has a context loaded with component scan feature for package com.mycom.project also searches for classpath*:META-INF/spring/*-context.xml.
So my question is - does this load controller's twice given that component scan is used for a for com.mycom.project.controllers and com.mycom.project? Or is it all loaded into one huge container and the contextConfigLocation parameter for either DispatcherServlet or global declaration is sort of access issue ? As in DispatcherServlet will reach only what's defined in servlet-context.xml but won't be able to use anything else?
And if my assumption is wrong, could I have a suggestion on how to manage multi-module project issues?
Thanks.
Yes, you might run into trouble. See this link for how to solve your problem.
#Service are constructed twice
The way you proceed when creating modules seems valid to me. You have a context.xml file for each module and all will get loaded once you load the application. Your modules are self-contained and can also be used in different environments. That's pretty much the way I'd also do it.
According to The IoC Container, Spring can manage a context hierarchy or hierarchy of containers and then use the <ref parent="beanId"/> to refer to a bean in a parent context. What mechanism does Spring use to create this container hierarchy? Can one use the <import resource="application-context.xml"/> command to create this hierarchy? Please provide an example of an application context that forms a hierarchy.
Application context hierarchy is created automatically; for example every Spring MVC application creates separate context for each DispatcherServlet. This context is a child of a common parent context. This way each child context can access beans from parent context, but not the other way around. Also sibling contexts are separated and invisible for each other.
You can create context hierarchy manually to provide finer level of granularity in your project. This can be achieved e.g. using various constructors of ClassPathXmlApplicationContext.
<import> construct merges beans from imported file, so it is a way of physically dividing bean definitions into several files, but they all end up in one context. BTW it's a pity there is no XML tag to define child context file (?)
Why do we use dispatcher
servlet.xml?
Is it something like web.xml?
Is application and dispatcher xmls
different from each other, are there
any similar things which both can
do?
I have a value, now i need to send
it to another class? can i do it via
application-context.xml
In addition to Nathans' answer - the dispatcher-servlet.xml defines a child context of the base application context (define in applicationContext.xml)
Child contexts have access to all the beans defined in the parent context, but parents don't have access to beans in the child contexts.
Because people don't want one humongous application-context.xml, they split them up by application layer.
No, it's just a Spring application context file.
They do the same thing.
That's not what it's for, it's for defining what your spring-managed objects get injected with.
Dispatcher servlet.xml is just the convention followed by the Spring front controller for web MVC applications. If you don't use Spring web MVC, you need not have a dispatcher-servlet.xml
web.xml is the configuration file required by a Java web app. You must have a web.xml for a Java web app, but the Spring servlet.xml is only required if you use Spring web MVC.
The Spring servlet XML is just part of a Spring web application configuration. You can put all your Spring configuration in the single XML file if you wish, but usually people have more than one.
Spring's bean factory creates objects and injects their dependencies. Your code does the rest. Define what "send it to another class" means to you.