spring mvc; contextConfigLocation load order - spring

I'm reconfiguring a webapp. I want to move everything out of dispatcher servlet into ContextLoaderListener. (This is due to changes in security configuration beyond the scope of this question)
Question 1, if I have multiple application context xml files, does it matter what order they are loaded? For example does the xml file containing context:component-scan need to be loaded before the xml file specifying DAO and service beans?
Question 2, (or is this moot?) how would I specify the order in which *_applicationContext.xml are loaded assuming that A_applicationContext.xml should be loaded before B_applicationContext.xml which should be loaded before C_applicationContext.xml
My web.xml is as follows:
<web-app id="WebApp_ID" version="2.4"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<servlet>
<servlet-name>AssessmentDelivery</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>AssessmentDelivery</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/config/*_applicationContext.xml</param-value>
</context-param>
<!-- security filter -->
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
</web-app>

Some suggestions:
For these days consider do the configuration for Spring through Javaconfig.
To answer questions 1 and 2 is very important you understand the following:
When you run the app Spring creates an Application Context where exists all the beans created and managed by Spring. Now consider that for that Application Context it should be created from two 'sub' applications contexts, normally they are 'mentioned' in the documentation how ServletApplicationContext and RootApplicationContext
The former should scan all about the Web, such as your #Controllers and #Bean's about infrastructure such as for ViewResolver etc..
The later should scan all about the Server, such as #Service and #Repositories and #Bean's about infrastructure such as for a DataSource etc.
Is very important understand the following:
ServletApplicationContext --> RootApplicationContext
It means the former can get access the latter (it about use dependencies i.e: a #Controller needs a #Service). Therefore it reflects that the Web side can access the server side.
Once said this the following is not possible
RootApplicationContext --> ServletApplicationContext
has no sense that a Bean from the server side want access the web side (a bad practice)
Long time ago I don't use web.xml but
DispatcherServlet + contextConfigLocation (through <init-param>) represents the ServletApplicationContext
ContextLoaderListener + contextConfigLocation (through <context-param>) represents the RootApplicationContext
It does not matter if the beans are declared through:
XML
JavaConfig
annotations #Controller etc.
Spring manages the cycle about in what order the beans are created. So do not matter how the .xml files (in your case) are declared (about the order).

Related

Understanding spring dispatcher servlet initialization

Here is how spring documentation recomends to initialize dispatcherServlet:
<web-app>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/root-context.xml</param-value>
</context-param>
<servlet>
<servlet-name>dispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value></param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
</web-app>
My question is about providing an empty param-value inside the init-param tag. Despite defining that param as context-param we still provide the empty value. Therefore contextConfigLocation should be null when passes to servlet's init() method. What's wrong, correct me please.
In Spring Web Applications, there are two types of container, each of which is configured and initialized differently.
Application Context
Web Application Context
Application context is inialised by config file's that you specified in as context-params and picked up by ContextLoaderListener. This is purely i would consider as business logic related beans.
Web application context is child of application context which may or may not be present. Each DispatcherServlet will have associated WebApplicationContext and which takes spring beans from your init-params to create context.
Whatever beans are available in the ApplicationContext can be referred to from each WebApplicationContext.
Reason why we have two different bean configurations is to keep a clear separation between middle-tier services such as business logic components and data access classes (that are typically defined in the ApplicationContext) and web- related components such as controllers and view resolvers (that are defined in the WebApplicationContext per Dispatcher Servlet).

Autowired not working if used inside class that extends Spring security class

I wasn't able to "autowire" inside a class that extends Spring security class (org.springframework.security.web.authentication.SimpleUrlAuthenticationSuccessHandler).
I made it working by adding, in security-config.xml, the following code, already written inside the xml spring configuration file: <context:annotation-config />, <context:component-scan base-package="packagename...."/> and the beans that I autowired.
I have two questions:
Why have I to write twice that code (both inside the xml spring
configuration file and security-config.xml)
Is there a way to tell security-config.xml to "look" for the code
written inside the xml spring configuration file? This way I
shouldn't write the code twice.
Thank you
Try to import your security-beans.xml from your main beans.xml.
Both files should be in the same folder. the import, for example:
<import resource="spring-security.xml"/>
In your web.xml, write something like this:
<!-- to integrate Spring -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring-servlet.xml</param-value>
</context-param>
2nd Approach - single beans.xml
Another approach, if you are afraid of imports, is to hold a single beans.xml that will include all beans - both the security beans as well as other beans. In this case, your web.xml will look like this:
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
<init-param>
<param-name>contextAttribute</param-name>
<param-value>org.springframework.web.servlet.FrameworkServlet.CONTEXT.spring</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
and your spring beans file will be spring-servlet.xml.
HTH.

Can Spring "live" alongside other servlets in the same webapp?

I've got the a WEB-INF/web.xml file with a couple of servlets, along with a context
listener which I use to bootstrap the application. I'd like to use Spring in this
web application. What's the best way to work Spring into this so I can use Spring's
injection mechanisms throughout the entire application - even in the servlets which
exists today?
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<display-name>Company's XMLRPC service</display-name>
<!-- Servlet Listeners -->
<listener>
<listener-class>com.company.download.context.DefaultServletContextListener</listener-class>
</listener>
<!-- Servlet Declarations -->
<servlet>
<servlet-name>DefaultTrackDownloadServlet</servlet-name>
<servlet-class>com.company.download.web.impl.DefaultTrackDownloadServlet</servlet-class>
</servlet>
<servlet>
<servlet-name>DefaultXmlRpcServlet</servlet-name>
<servlet-class>com.company.download.web.impl.DefaultXmlRpcServlet</servlet-class>
</servlet>
<!-- Servlet Configurations -->
<servlet-mapping>
<servlet-name>DefaultTrackDownloadServlet</servlet-name>
<url-pattern>/track</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>DefaultXmlRpcServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
</web-app>
Can Spring “live” alongside other servlets in the same webapp?
Yes, Spring MVC is basically just a DispatcherServlet that can make use of a ContextLoaderListener.
These two classes are already setup to interact with one or more ApplicationContext instances and have Spring manage the declared beans.
Your custom Servlet classes are not. If you need to inject a bean into your own Servlet instances, you need to get a reference to the ApplicationContext from the ContextLoaderListener and get the beans you want. There are a few options, whether you do it yourself or use built-in features.
The ContextLoaderListener stores the ApplicationContext it loads into a ServletContext attribute named
org.springframework.web.context.WebApplicationContext.ROOT
So you can retrieve it with that (there's a constant for easy use)
ApplicationContext ac = (ApplicationContext) config.getServletContext().getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
Other options exist, see some of them here:
Autowiring in servlet
I want to inject an object in servlet using Spring

Singleton bean in two contexts spring

I have a web application context(for DISPATCHER) and also Web Services context(for MESSAGE DISPATCHER) in a web application.
I have one bean which is singleton and i need that bean in both contexts.
if i specify the bean as singleton in both contexts then it is not singleton any more.
please suggest a solution or guide me in right direction.
<servlet>
<servlet-name>ws</servlet-name>
<servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
<init-param>
<param-name>transformWsdlLocations</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ws</servlet-name>
<url-pattern>/service/*</url-pattern>
</servlet-mapping>
<servlet>
<servlet-name>mvc</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>mvc</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>mvc</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
If I understand your question correctly, you have a web application context (e.g. *-servlet.xml) and a root application context (e.g. applicationContext.xml). Web application context extends application context, so that it can access beans from the parent, but not the other way around, so beans which need to be accessed in both should be in applicationContext.xml
See:
Difference between applicationContext.xml and spring-servlet.xml in Spring Framework and
What is the difference between ApplicationContext and WebApplicationContext in Spring MVC? and
ContextLoaderListener or not?
Edit:
In your web.xml you have two ServletContexts, but no root context. The answer to What is the difference between ApplicationContext and WebApplicationContext in Spring MVC? has an excellent explanation of this, but in short you will need to load the root application context by adding the following to web.xml:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:META-INF/spring/applicationContext*.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
which will then load the root application context from applicationContext.xml. Beans in the root application context will be accessible in both ServletContexts. You would usually want only web related beans (Controllers etc) in you ServletContexts, and shared business logic in the root application context.
If the bean needs to be used in two different contexts, define it in a separate application context xml file, then create three application contexts:
Root context - contains shared bean(s)
App context 1. e.g. web app. Has the root context as a parent.
App context 2. e.g. web services interface, also has the root context as a parent.
The bean will be instantiated once when the root application context is created. Both the child app contexts can then use that singleton bean.

spring 3 mvc multiple application context instances

here is my web.xml:
<?xml version="1.0" encoding="UTF-8"?><web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<!-- Enables clean URLs with JSP views e.g. /welcome instead of /app/welcome -->
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring/*.xml
</param-value>
</context-param>
<!-- Handles all requests into the application -->
<servlet>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring/*.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<!-- Maps all /app requests to the DispatcherServlet for handling -->
<servlet-mapping>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Why there are two instances of application context created?
When I add a scheduled method with #Scheduled it is invoked twice, because of those two application contexts.
You are loading twice times the same spring config files. Of course you have two separate application contexts. At first I would rename the servlet name for the DispatcherServerlet to "spring3mvc". The servlet definition should look like this:
<servlet>
<servlet-name>spring3Mvc</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
If you have it in this way, you should have a spring config file "spring3Mvc-servlet.xml" in your "WEB-INF" directory. Spring will find this file automatically because of the right naming convention. In this file you should just have the beans who are important for springMVC. It could look like this:
<context:component-scan base-package="org.company.gui.controller"/>
<bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".view.jsp"/>
</bean>
This should fix your problem.
I noticed that you have
<load-on-startup>1</load-on-startup>
in the following block
<servlet>
<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>
/WEB-INF/spring/*.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
try removing that... it worked for me
Do you have any other spring filters or jsp pages in your web.xml not shown in your code snippet?
I ask, to answer your question, because I believe this quote from Spring documentation could explain what might be happening...
"In the web MVC framework, each
DispatcherServlet has its own
WebApplicationContext, which inherits
all the beans already defined in the
root WebApplicationContext. These
inherited beans defined can be
overridden in the servlet-specific
scope, and new scope-specific beans
can be defined local to a given
servlet instance."
If you answered "yes" to my web.xml question, then my guess is that Spring instantiates a root WebApplicationContext when a spring filter is created (via ContextLoaderListener). So, this would happen BEFORE...
Then, when the DispatcherServlet is created, the "contextConfigLocation" refers to the same files (that is, the same bean names), so a new WebApplicationContext gets overridden bean names local to that servlet!
I wonder, even if you answered "no", whether this might still happen anyway. Since you set "contextConfigLocation" (used by the ContextLoaderListener) and "override" it in DispatcherServlet configuration; I assume Spring is not checking whether those configurations are using the same file set.
You can run these scenarios through a debugger and put breakpoints on WebApplicationContext methods to find out for sure.
Workaround:
To solve the problem, either:
1) make sure your 2 contextConfigLocations don't overlap in files they use
Or:
2) break out the Scheduling bean in its own xml file and make sure it's referred to by only one of the 2 contextConfigLocations

Resources