Root and child contexts
Before reading further, please understand that –
Spring can have multiple contexts at a time. One of them will be root context, and all other contexts will be child contexts.
All child contexts can access the beans defined in root context; but opposite is not true. Root context cannot access child contexts beans.
ApplicationContext :
applicationContext.xml is the root context configuration for every web application.
Spring loads applicationContext.xml file and creates the ApplicationContext for the whole application.
There will be only one application context per web application.
If you are not explicitly declaring the context configuration file name in web.xml using the contextConfigLocation param, Spring will search for the applicationContext.xml under WEB-INF folder and throw FileNotFoundException if it could not find this file.
ContextLoaderListener
Performs the actual initialization work for the root application context.
Reads a “contextConfigLocation” context-param and passes its value to the context instance, parsing it into potentially multiple file paths which can be separated by any number of commas and spaces, e.g. “WEB-INF/applicationContext1.xml, WEB-INF/applicationContext2.xml”.
ContextLoaderListener is optional. Just to make a point here: you can boot up a Spring application without ever configuring ContextLoaderListener, just a basic minimum web.xml with DispatcherServlet.
DispatcherServlet
DispatcherServlet is essentially a Servlet (it extends HttpServlet) whose primary purpose is to handle incoming web requests matching the configured URL pattern. It take an incoming URI and find the right combination of controller and view. So it is the front controller.
When you define a DispatcherServlet in spring configuration, you provide an XML file with entries of controller classes, views mappings etc. using contextConfigLocation attribute.
WebApplicationContext
Apart from ApplicationContext, there can be multiple WebApplicationContext in a single web application.
In simple words, each DispatcherServlet associated with single WebApplicationContext.
xxx-servlet.xml file is specific to the DispatcherServlet and a web application can have more than one DispatcherServlet configured to handle the requests.
In such scenarios, each DispatcherServlet would have a separate xxx-servlet.xml configured. But, applicationContext.xml will be common for all the servlet configuration files.
Spring will by default load file named “xxx-servlet.xml” from your webapps WEB-INF folder where xxx is the servlet name in web.xml.
If you want to change the name of that file name or change the location, add initi-param with contextConfigLocation as param name.
Comparison and relation between them :
ContextLoaderListener creates root application context.
DispatcherServlet entries create one child application context per servlet entry.
Child contexts can access beans defined in root context.
Beans in root context cannot access beans in child contexts (directly).
All contexts are added to ServletContext.
You can access root context using WebApplicationContextUtils class.
After reading the Spring documentation, following is the understanding:
a) Application-Contexts are hierarchial and so are WebApplicationContexts. Refer documentation here.
b) ContextLoaderListener creates a root web-application-context for the web-application and puts it in the ServletContext. This context can be used to load and unload the spring-managed beans ir-respective of what technology is being used in the controller layer(Struts or Spring MVC).
c) DispatcherServlet creates its own WebApplicationContext and the handlers/controllers/view-resolvers are managed by this context.
d) When ContextLoaderListener is used in tandem with DispatcherServlet, a root web-application-context is created first as said earlier and a child-context is also created by DispatcherSerlvet and is attached to the root application-context. Refer documentation here.
When we are working with Spring MVC and are also using Spring in the services layer, we provide two application-contexts. The first one is configured using ContextLoaderListener and the other with DispatcherServlet
Generally, you will define all MVC related beans (controller and views etc) in DispatcherServlet context, and all cross-cutting beans such as security, transaction, services etc. at root context by ContextLoaderListener.
References :
https://javabeat.net/spring-mvc-application-context/
https://schoudari.wordpress.com/2012/07/23/purpose-of-contextloaderlistener-spring-mvc/
https://howtodoinjava.com/spring-mvc/contextloaderlistener-vs-dispatcherservlet/
Before reading further, please understand that –
Spring can have multiple contexts at a time. One of them will be root context, and all other contexts will be child contexts.
All child contexts can access the beans defined in root context; but opposite is not true. Root context cannot access child contexts beans.
ApplicationContext :
applicationContext.xml is the root context configuration for every web application.
Spring loads applicationContext.xml file and creates the ApplicationContext for the whole application.
There will be only one application context per web application.
If you are not explicitly declaring the context configuration file name in web.xml using the contextConfigLocation param, Spring will search for the applicationContext.xml under WEB-INF folder and throw FileNotFoundException if it could not find this file.
ContextLoaderListener
Performs the actual initialization work for the root application context.
Reads a “contextConfigLocation” context-param and passes its value to the context instance, parsing it into potentially multiple file paths which can be separated by any number of commas and spaces, e.g. “WEB-INF/applicationContext1.xml, WEB-INF/applicationContext2.xml”.
ContextLoaderListener is optional. Just to make a point here: you can boot up a Spring application without ever configuring ContextLoaderListener, just a basic minimum web.xml with DispatcherServlet.
DispatcherServlet
DispatcherServlet is essentially a Servlet (it extends HttpServlet) whose primary purpose is to handle incoming web requests matching the configured URL pattern. It take an incoming URI and find the right combination of controller and view. So it is the front controller.
When you define a DispatcherServlet in spring configuration, you provide an XML file with entries of controller classes, views mappings etc. using contextConfigLocation attribute.
WebApplicationContext
Apart from ApplicationContext, there can be multiple WebApplicationContext in a single web application.
In simple words, each DispatcherServlet associated with single WebApplicationContext.
xxx-servlet.xml file is specific to the DispatcherServlet and a web application can have more than one DispatcherServlet configured to handle the requests.
In such scenarios, each DispatcherServlet would have a separate xxx-servlet.xml configured. But, applicationContext.xml will be common for all the servlet configuration files.
Spring will by default load file named “xxx-servlet.xml” from your webapps WEB-INF folder where xxx is the servlet name in web.xml.
If you want to change the name of that file name or change the location, add initi-param with contextConfigLocation as param name.
Comparison and relation between them :
ContextLoaderListener creates root application context.
DispatcherServlet entries create one child application context per servlet entry.
Child contexts can access beans defined in root context.
Beans in root context cannot access beans in child contexts (directly).
All contexts are added to ServletContext.
You can access root context using WebApplicationContextUtils class.
After reading the Spring documentation, following is the understanding:
a) Application-Contexts are hierarchial and so are WebApplicationContexts. Refer documentation here.
b) ContextLoaderListener creates a root web-application-context for the web-application and puts it in the ServletContext. This context can be used to load and unload the spring-managed beans ir-respective of what technology is being used in the controller layer(Struts or Spring MVC).
c) DispatcherServlet creates its own WebApplicationContext and the handlers/controllers/view-resolvers are managed by this context.
d) When ContextLoaderListener is used in tandem with DispatcherServlet, a root web-application-context is created first as said earlier and a child-context is also created by DispatcherSerlvet and is attached to the root application-context. Refer documentation here.
When we are working with Spring MVC and are also using Spring in the services layer, we provide two application-contexts. The first one is configured using ContextLoaderListener and the other with DispatcherServlet
Generally, you will define all MVC related beans (controller and views etc) in DispatcherServlet context, and all cross-cutting beans such as security, transaction, services etc. at root context by ContextLoaderListener.
References :
https://javabeat.net/spring-mvc-application-context/
https://schoudari.wordpress.com/2012/07/23/purpose-of-contextloaderlistener-spring-mvc/
https://howtodoinjava.com/spring-mvc/contextloaderlistener-vs-dispatcherservlet/
No comments:
Post a Comment