Join Ketkee Aryamane for an in-depth discussion in this video Understanding forwarding, part of Java EE: Servlets and JavaServer Pages (JSP).
- [Woman] Now let us understand the concept of forwarding in servlets specification. All of the demos that we have implemented so far follow this flow. There's a requested ghost from the client to the servlet, the servlet will extract the request data, bundle it up in objects, and call the dao. The dao then talks to the database and returns the data in the sublet. The sublets are then going to prepared the response and give it back to the client, which in turn, is going to display it. Now in this entire process, we have actually asked the servlet to write the response back.
Often in a web application, all the requests processing capability is never encapsulated into a single servlet. You often need to split up the functionality across multiple servlets to make the code more modular and maintainable. In that case it is necessary to understand how do you forward the control of the request from one servlet to another? Even in cases where the servlet is trying to ready the response and give it back to the client, we need to understand how do you forward the control from the servlet to let's say a JSP file.
So far, we've not seen any JSP files, we always deal with HTML's, but that's definitely a need that's coming up in future. So let's look at this diagram. Whenever the user hits a request, it goes to your application context. Let's say that this requests functionality is split across servlet. So the request comes to the first servlet and when the servlet does what it is supposed to do, the request can be forwarded to the other servlet. Not only this, in some cases the servlet can also forward the entire request control to another JSP.
Now be it a servlet or a JSP, they are all resources of the application. So this process by which you can forward the request control from one servlet to another servlet or from one servlet to another JSP is exactly the concept of forwarding under the servlets API. Now let us look at a use case in our application. What we are going to do now is, we are going to make this login link functional. For this, I have already got the login.jsp file ready with me in my HTML folder.
Of course, right now it doesn't have any capabilities of JSP, but I have just renamed it to a .JSP file. This is that index.html, which has got the login link. If I want to make that login link functional, I can access that login JSP from here as a static resource. How do I do that? I just have to go ahead and embed the bot of that JSP right out here, on line number 21. Now, let's also go to login.jsp and take a look at it.
So it has got a header, it has got some details, and a footer. If you look at the resources that it has accessed, for example, on line number seven, it is accessing the CSS, on line number 17, it's accessing some image, these spots that you see are the bots as for the war structure that we've seen previously. But now, in order to make this demo work, I'm going to access these resources as well in a static fashion. So that's how I do it. So let me get those bot changes on line number seven, line number 17, and down there where you have the footer on line number 59.
Now let's go ahead and run this application and see whether our changes work correctly, so I'm going to run this project. Let's take this and go to our browser. And run this. Now when I click on login, do you see that I reached the login.jsp file? I accessed the login.jsp as a static resource. Now please take a look at the URL. If you observe the URL you'll see that the folder details of login.jsp are visible out there.
This is not a very wise thing to do, because we wouldn't want to reveal the implementation details like that to the end customers. Now, this entire scenario that we did right now, I'm going to implement using our forwarding concept. What we are going to do is, when I click on the login link, I'm going to reach a login servlet, and from the login servlet, I will go over to the login JSP. So let's work that out. Now, in order to do the forwarding, you need an API, which is RequestDispatcher.
As the name suggests, it is going to dispatch your request to another resource of the application. You need to get the RequestDispatcher API on the HTTPServletRequest object. So let's get started with this demo. I'm going to open my eclipse. I have the login servlet ready with me, which extends HttpServlet, and it has been annotated with the URL pattern of login. There's a doGet material on line number 15, and the sole object of this meter is to reach that login JSP.
For that, I'm going to need the RequestDispatcher API. So on line number 17, I'm going to take a reference of it. I can opt in the object for this on the request object, but in working in API called getRequestDispatcher, and this will demand the part of that resource where you want to go to. (typing noises) Once this is done, the next step will be to call the RequestDispatcher.forward API to hand over the request control to another resource.
So just getting the dispatcher reference would not be enough, what we essentially have to do is on the next line, which is line number 18, I'm just going to invoke an API called forward, and pass the request and response objects along with it. This is forwarding. You are in the login Servlet, but you're using the RequestDispatcher to forward the control to the login.jsp file. So a question may float in the mind here as to why are we including the request and response objects when we forward the call? That's because, let's say the current resource wants to utilize request and response, the other resource where you're forwarding to, that may also need to use both of these objects for let's say extracting the request data, writing some more response, etc.
So even if this login servlet was not doing anything with these objects, the next resource in line would definitely need these. That's exactly why the specification itself dictates that whenever you forward the control to another resource, make sure that the requested response objects always go along. Now let's come in index.html, get rid of the static access of this, and embed the URL pattern of that servlet, so that when we click here, it takes us to the servlet. On the login.jsp also, I need to stop accessing these resources in a static fashion.
So let's do those changes. This is line number 17, and that's line number seven. So I'm going to go back to my previous changes. Once this is done, let me now deploy the project again and check the changes. Now when I click on this login hyperlink, let's see what happens. Yes, I indeed reach the login.jsp file, but take a look at the URL. The URL only shows the login URL pattern, and that's exactly why we are safe now.
It is not revealing any kind of implementation details in the URL. This exactly is the concept of forwarding. There are a couple of other things in this. There's another API called RequestDispatcher.include that you can use. Let's go back to our servlet and examine how to do this. You are in the servlet, and on line number 19, instead of forward, I am now going to call the include API. What it essentially does is, it is going to combine the response of this login servlet and the response of this login.jsp file together and render it to the client.
In order to do this demo, just for the demo purposes, I'm going to construct a small response inside login servlet. On line number 18, I'm just constructing a very small HTML. And under that HTML, let's write out a simple H3 tag, which will display a message stating please login. Let me end the H3 tag, and this string is ready with us.
Now we just need to get the writer object and invoke the right API and stuff that HTML response inside that call. So now, what is going to happen is that this response, which is written out of the login servlet, and whatever happens as a part of login JSP, it's going to combine together, and it's going to get rendered to the client. So let's check the changes for this. So now let's say I click on the login hyperlink. Do you see what happened? I got a message at the top, which is please login, which is the response coming out of the login servlet, and I also got the entire login JSP rendered to the client, so this is a combination of response, which is possible with the help of the include API.
So this is how RequestDispatcher works. It's basically used to forward the control from one resource to another resource, but do not forget it is inside the same application. And in this entire process, the browser will play no part. Entirely, it's managed by the server site. This approach is very commonly used in a framework called Struts, where whenever you click on a hyperlink, you always go to an action class and from the action class, the request is dispatched to a JSP. That way, we are always safe, and we never reveal any of our folder details in the URL.
- Reviewing the purpose of servlets
- Implementing a GET request in a web app
- POST request basics
- Forwarding, redirection, and other APIs
- Servlet life cycle
- Reviewing JSP and its features
- Session management
- Filters and Listeners
- Using expression language in JSP
- Need for JSTL and its modules