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.
Related
In the web.xml I like to specify multiple Spring DispatcherServlet config xml files, such that I can add additional beans in test/demo/etc.. environments.
However, how can I specify that Spring has to ignore xml files that don't exists?
Currently I receive an exception when Spring can't find the config file, for example: "demo/front.xml" (it works when the file is present).
My web.xml snippet:
bv-web
org.springframework.web.servlet.DispatcherServlet
contextConfigLocation
classpath:front.xml,classpath:${app.env}/front.xml
Alternative:
As an alternative I tried to add extra beans through the root applicationContext.xml (using ClassPathXmlApplicationContext) which work as long as it concerns old-fashion Spring controllers that extend "AbstractController".
However, when using the #Controller and #RequestMapping annotations, the controllers are created and added to "a" DispatcherServlet, but aren't used by the DispatcherServlet. It's like I have multiple DispatcherServlets :(.... I think because they live in different Spring Application contexts (strange however that it works with the old-fashion controller mechanism).
This question already has answers here:
Difference between applicationContext.xml and spring-servlet.xml in Spring Framework
(6 answers)
Closed 9 years ago.
Why do we need applicationContext.xml in Spring?
In what situation would we use it? Do you have an example?
What is the difference between applicationContext.xml and spring-servlet.xml?
How can we compare applicationContext.xml in Spring with Struts.xml in Struts for easy understanding?
Why do we need applicationContext.xml in Spring?
In the early days of Spring framework, Application context i.e the various weave and settings necessary to bootstrap, coordinate and control all objects, where done using XML file. Although one can break various settings and dependency injection into several context files, this process has been made easier In Spring 2.5 and later by annotation-driven settings.
What is the difference between applicationContext.xml and spring-servlet.xml?
In a MVC based project, again if you're not using annotation-driven weaving mechanism for your project, all your endpoint servlets can be setup in the spring-servlet.xml. Note that the name of the file is always self chosen.
How can we compare applicationContext.xml in Spring with Struts.xml in Struts for easy understanding?
They are both similar in terms of what they're trying to achieve. i.e a central location for the application bootstrap settings. Similarly, all settings can be tiered into different files to make it modular.
applicationContext comes from Spring Framework: it manages the business/DAO beans.
spring-servlet comes from Spring MVC: it manages the web beans.
A Web application can have many servlets running at the same time, therefore:
spring-servlet.xml will hold beans only visible to a particular servlet.
You could have many different servlets running
spring-servlet2.xml
spring-servlet3.xml
messaging-servlet.xml
etc.
applicationContext.xml will hold application wide beans. Therefore all the servlets running will have access to the beans defined in applicationContext.xml. However, this is a one way dependency, your servlets can access you applicationContext.xml beans but your applicationContext cannot access any of your servlet beans.
I am trying to setup a session scoped bean but the spring document said that session scope is only applicable on web-aware application context. No further explanation in the doc. Can someone clarify this?
This means that you can only use the session scoped beans in a an application deployed to a web server. Spring can be used in applications that run in standard JVMs along with applications that run in servlet containers (Tomcat, etc). Session, however, only exists in web servers so it has no meaning if the application is running in a standard desktop environment.
There are basically 5 types of scopes available for spring bean.
1)Singleton
2)Prototype
3)Request
4)Session
5)Global-Session
The first two scopes can be used with any type of spring applications.
But the remaining 3 are related to web applications. They can be used only with the spring applications which are involved in web.
Web aware means when the application provides web endpoints for third party client. I.E When the application contains at least one RestController . You can do this by simply adding #RestController annotation to your class.
ApplicationContext is an interface, spring ships multiple ApplicationContext implementations, according to documentation you need to use one that is web-aware.
The request, session, application, and websocket scopes are available only if you use a web-aware Spring ApplicationContext implementation (such as XmlWebApplicationContext). If you use these scopes with regular Spring IoC containers, such as the ClassPathXmlApplicationContext, an IllegalStateException that complains about an unknown bean scope is thrown.
And as of spring framework core (6.0.4) further configuration might be required:
To support the scoping of beans at the request, session, application, and websocket levels (web-scoped beans), some minor initial configuration is required before you define your beans.
...
If you access scoped beans within Spring Web MVC, in effect, within a request that is processed by the Spring DispatcherServlet, no special setup is necessary. DispatcherServlet already exposes all relevant state.
If you use a Servlet web container, with requests processed outside of Spring’s DispatcherServlet (for example, when using JSF), you need to register the org.springframework.web.context.request.RequestContextListener ServletRequestListener. This can be done programmatically by using the WebApplicationInitializer interface. Alternatively, add the following declaration to your web application’s web.xml file:
<web-app>
...
<listener>
<listener-class>
org.springframework.web.context.request.RequestContextListener
</listener-class>
</listener>
...
</web-app>
Spring boot will automatically configure this for you (couldn't find documentation mentioning this explicitly).
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.
consider a JSF web application with a managed bean FooBean.java. I've declared this "FooBean" in my faces-config.xml file. Now, if I want to add the Spring AOP advice for the methods of FooBean, how do I do that?
Should I add an applicationContext.xml file and declare the managed beans inside it?
or will it work even if I am not declaring the managed beans inside a Spring configuration file?
Note: I've created an Aspect bean and defined a point-cut like #Pointcut("within(dummy.web.reporting..*)") inside the aspect bean.
You can load a regular spring context xml file from within your web.xml like so:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/classes/spring-context.xml</param-value>
</context-param>
You can then define your managed beans in here in the regualar spring way and you can still refer to these beans by id in your jsps.
You will also be able to use all the standard Spring AOP stuff within your spring-context.xml
I am using Spring AOP heavily in a Spring JSF application, I would rather suggest you to load your JSF beans via Spring container and also let Spring manage the Scope of the beans.
In such a scenario all beans would be loaded by Spring container thus it would become very easy to implement Spring AOP.
More info on such type of Spring-JSF integration
http://xebee.xebia.in/2011/10/31/spring-jsf-integration-made-easy-clean-using-spring-annotations/