Will multiple dispatcherservlet will share controller and other components in spring MVC
They are working by servlet specification which means that they won't share. It will just for different URI mappings dispatch by different servlets as it suppose to be for servlet. Those controllers should present in web application context provided for dispatcherServlet instance. You can reuse controllers from different contexts.
Dispatcher servlet should be just one as it implements front controller pattern. I don't understand why you need multiple instances in the first place.
Related
I am new to spring. I wanted to know two things :
Does the Dispatcher Servlet and ApplicatonContext exists in two different containers (in terms of spring).
Also, if they are part of same container, then how is it possible that spring is creating two beans if I scan the classes in both of their config files?
Will be very thankful for any help.
SpringMVC has one Container i.e WebApplicationContext(Interface)
A Context represents your environment. It represents the state surrounding where you are in your system. For example, in web programming in Java, you have a Request, and a Response. These are passed to the service method of a Servlet. A property of the Servlet is the ServletConfig, and within that is a ServletContext. The ServletContext is used to tell the servlet about the Container that the Servlet is within. So, the ServletContext represents the servlets environment within its container. Similarly, in Java EE, you have EBJContexts that elements (like session beans) can access to work with their containers.(copy/paste from qoura)
What is the difference between DispatcherServlet and ContextLoaderListener in Spring framework? Do we need to configure both of them in web.xml when we are using spring framework?
AFAIK each DispatcherServlet will have a WebApplicationContext. By default the DispatcherServlet looks for a spring configuration file named [appname]-servlet.xml under WEB-INF folder.
Do we need to configure DispatcherServlet?
Yes, every spring application should configure DispatcherServlet as it is the one through which all the requests are routed. It decides the appropriate method of the controller class to handle the request. Once controller returns the model along with the logical view, DispatcherServlet takes the help of ViewResolver to resolve the view (generally JSPs) and will pass the model data to the view, which is finally rendered on the browser.
Do we need to configure ContextLoaderListener?
No, this is not mandatory. Spring applications can live with out ContextLoaderListener.
Why do we need ContextLoaderListener?
Usually when we build multi-tier applications we don't want to clutter all the beans in one config file [appname]-servlet.xml. For example if you configure spring security you wanted to include all those beans in security-context.xml, in the same way all the beans belonging to service layer are configured in applicationContext.xml and some would like to configure beans belonging to DAO layer in dao-context.xml. So when you configure all these beans in different context files, you need to let know spring that these files exist as spring only knows about [appname]-servlet.xml. ContextLoaderListener will help spring recognize all the other context files.
Hope this helps!
The root WebApplicationContext is a Spring Application Context shared across the application.
A DispatcherServlet instance actually has its own
WebApplicationContext.
One can have multiple DispatcherServlet instances in an application, and each will have its own WebApplicationContext.
The root WebApplicationContext is shared across
the application, so if you have a root WebApplicationContext and
multiple DispatcherServlets, the DispatcherServlets will share the
root WebApplicationContext.
However, for a simple Spring MVC application, one can even have a situation where there is no need to have a root WebApplicationContext. A DispatcherServlet would still have its own WebApplicationContext, but it doesn’t actually need to have a parent root WebApplicationContext.
So, which beans should go in the root Web Application Context and which beans should go in the DispatcherServlet’s Web Application Context?
Well, general beans such as services and DAOs make their way in root Web Application Context, and more web-specific beans such as controllers are included in DispatcherServlet’s Web Application Context.
When DispatcherServlet starts up, it creates a Spring application context and starts
loading it with beans declared in the configuration files or classes that it’s given.
But in Spring web applications, there’s often another application context. This
other application context is created by ContextLoaderListener
Whereas DispatcherServlet is expected to load beans containing web components
such as controllers, view resolvers, and handler mappings, ContextLoaderListener is
expected to load the other beans in your application. These beans are typically the
middle-tier and data-tier components that drive the back end of the application.
Good luck!
I have fundamental idea about servlet and spring mvc. But I don't know that there is a usage of servlets in spring mvc or not. In spring mvc we have controller classes. My thinking is servlet is used in spring mvc as a controller. If I'm incorrect please correct me.
Yes,you are perfectly right. Servlets are used in Spring-MVC. In Spring-MVC when you write annotation like #Controller, indirectly you are using a Servlet called Dispatcher Servlet. Dispatcher Servlet is defined in web.xml file with properties and class name which is mapped to .jsp pages and Controller part.
Related / Duplicated to When to use Servlet or #Controller. The question is not the same but quite the explanation on that question you will be able to understand:
If you're a student interested in learning the language then I would stick with servlets for now. It's possible to write a web app using just servlets but in practice you'll probably want to look at JSP's too.
A JSP is a convenient way to write a servlet that allows you to mix html with scripting elements (although it's recommended to avoid Java code in your jsp in favour of tags and el expressions). Under the covers it will be compiled as a servlet but it avoids you having to use lots of messy print statements.
It's important to have at least a basic understanding of servlets and JSP's. Spring MVC is one of many frameworks built on top of servlets to try make the task of writing a web application a bit easier. Basically all requests are mapped to the DispatcherServlet which acts as a front controller.
The DispatcherServlet will then call the controller whose annotations match the incoming request. This is neater than having to write these mappings yourself in the web.xml (although with servlet 3.0 you can annotate servlets now). But you also get many other benefits that can be used like mapping form fields to an object, validating that object with jsr303 annotations, map inputs and outputs to xml or json etc etc. Plus it's tightly integrated with core spring so you can easily wire in your services for the controller to call.
It's worth noting that there are a plethora of competing frameworks built on top of servlets. Spring MVC is one of the most popular so it's not a bad choice to look into.
Controllers are not Servlets! Controllers are normal Spring MVC beans that do not extend HttpServlet. Instead what Spring has is a custom extension of HttpServlet called DispacherServlet. Looking at the DispacherServlet's source code you can see that the class hierarchy goes: DispatcherServlet extends FrameworkServlet → FrameworkServlet extends HttpServletBean → HttpServletBean extends HttpServlet.
The DispatcherServlet, like any other Servlet, is declared in the web.xml. It handles all incoming HTTP requests. It is called a front controller which provides a single point of entry in your application. It is responsible for request handling by delegating requests to additional components of Spring MVC controllers which do not extend the HTTP Servlet API.
Look at the following diagram
In this picture DispacherServlet is the only HttpServlet. The Controllers, HandlerMapping and ViewResolver are all Spring MVC beans.
How does Dispatcher Servlet works internally?
I have seen that Controllers and it methods(defined by us) can be annotated with #RequestMapping and many other attributes. These controller has methods that have **varying signatures (Thay can take any parameter we like).
How does the Dispatcher servlet know how to pass these parameters in the methods defined by us? I mean how does Dispatcher Servletprepare these objects which we require in the controller methods?
Also what actually happens in WebApplicationContext behind the scenes?
would suggest to read section 15.2 this describes internal about spring mvc framework.
Spring MVC uses a DispatcherServlet to route control to an appropriate Controller. But where do filters fit into the flow? If I specify a filter to perform session management or authentication, will the filters always be called before DispatcherServlet?
My confusion comes from the fact that they both specify a URL pattern. What happens if they both provide the same url pattern?
This is not really specific to Spring and Spring MVC. In general fitlers are always called before servlets. When you have several filters and one servlet matching given URL pattern, all filters are executed first in the order of <filter-mapping> definitions and the servlet is executed last.
This way you can modify the request on the fly or even ignore the servlet altogether.