How to Map Servlet Actions to JSP Path with Annotations? - java

I have a simple Maven servlet/jsp application that I deploy to a local Tomcat 9 (via Eclipse). JSP pages are stored under root folder (src\main\webapp\*.jsp) which when Maven installs a WAR, they go under the root folder (MyAppContext\*.jsp along side MyAppContext\META-INF\ and MyAppContext\WEB-INF\).
The servlets' URL patterns are annotated for each servlet, e.g. /doactionone, /doactiontwo, etc. Most servlets perform the dispatching to various JSP pages, but I do have a direct anchor link on one.
I wanted to move these JSP pages into their own respective directory, so I moved them to src\main\webapp\jsp\*.jsp folder, and when the Maven install is run, they get placed under MyAppContext\jsp\.
The only entry I have in web.xml is a welcome file that after relocating the JSP files, it points to jsp\doactionone.jsp which loads that corresponding JSP page. This page contains a simple form:
<form action="doactionone" method="post">
...
<a href="jsp/doactiontwo.jsp">
<input type="submit" />...
</form>
The submission on this page actually calls the right servlet (the one defined with doactionone URL pattern). I also have a link that takes the user to the second page (doactiontwo.jsp).
However, when I navigate to that second page via this link, which has another simple form (see below), and perform the submission (post), I see in browser's debugging that the URL request is http://localhost:8080/MyAppContext/jsp/doactiontwo which, for obvious reason, would return a 404 status (and get no hit to this servlet's doPost() (or doGet()) methods either).
<form action="doactiontwo" method="post">
...
<input type="submit" />...
</form>
If I try to modify the second servlet's URL pattern to /jsp/doactiontwo, I can hit the servlet, but when doactiontwo actually dispatches/forwards the request after processing to the first servlet (doactionone) with:
RequestDispatcher rd = request.getRequestDispatcher("doactionone.jsp");
rd.forward(request, response);
when it gets loaded, when hover over the URL on the first page that initially was pointing to the second JSP page (<a href="jsp/doactiontwo.jsp">), now actually points to:
jsp/jsp/doactiontwo.jsp
The funny part is that the source code of doactionone.jsp still shows it as jsp/doactiontwo.jsp, but hovering over it shows http://localhost:8080/MyAppContext/jsp/jsp/doactiontwo, and when clicked, it obviously results in 404 status.
Can somebody explain why, first of all, the submission on the second JSP page requires the servlet to have a pattern of /jsp/doactiontwo to work rather than /doactiontwo? And is there a way around to avoid appending /jsp to the URL pattern?
And second, why when the second servlet processes the request and dispatches/forwards it to the first page, the URL now contains two jsp/'s?

You need to change your design to allow the controllers, a.k.a. Servlets, to drive your application. In this particular case, use the URL Pattern of second Servlet (doactiontwo) in place of you link:
#WebServlet(urlPatterns = { "doactiontwo" }
public class DoActionTwoServlet extends HttpServlet { /* ... */ }
<form action="doactionone" method="post">
...
<a href="doactiontwo"> <!-- This should match your second servlet's URL pattern -->
<input type="submit" />...
</form>
Now, since the default method when anchor link is invoked is GET, you need to overwrite DoActionTwoServlet's doGet() method, and forward those requests to an actual doactiontwo.jsp:
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
RequestDispatcher rd = request.getRequestDispatcher("jsp/doactiontwo.jsp");
rd.forward(request, response);
}

Related

Why I need mapping or annotation for Servlet, but not for JSP?

To make a request to Servlet, I need to use mapping inside XML file or add annotation for given Servlet. But why I am not required to do the same for JSP files as well? I will give examples.
How does this work?
index.html:
<html><body>
<form action="result.jsp">
<button>go</button>
</form>
</body></html>
result.jsp:
<html><body>
hello
</body></html>
Notice I didn't have to use any XML mappings nor annotations. It just "finds" it.
But how this doesn't work?
index.html:
<html><body>
<form action="com.example.MyServlet">
<button>go</button>
</form>
</body></html>
com.example.MyServlet:
public class MyServlet extends HttpServlet {
#Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
PrintWriter pw = resp.getWriter();
resp.setContentType("text/html");
pw.println("hello");
}
}
Here, I get error: The requested resource [/TestProject/com.example.MyServlet] is not available. How? How come I didn't need to use XML, nor annotations for JSP, but I had for Servlet? Shouldn't they work the same way, as JSP eventually turns to Servlet. So why is there different behavior? I know I am missing something, I just don't know what...
Why I need mapping or annotation for Servlet, but not for JSP?
As pointed out in the comment above from #SotiriosDelimanolis, that's not what actually happens. A JSP is eventually turned into a servlet and behaves like any other servlet you define on your own. And when you define a servlet you also need to add a URL mapping so that an URL path is resolved to a servlet that can respond to a request made for that URL.
The only difference is that for JSP files this mapping is done implicitly by the servlet container. For the servlets you define, you obviously need to define your own mapping because the server can't know what you want to do with the servlet in your own application.
The specifications says the following (emphasis mine):
A web component is either a servlet or a JSP page. The servlet element in a web.xml deployment descriptor is used to describe both types of web components. JSP page components are defined implicitly in the deployment descriptor through the use of an implicit .jsp extension mapping, or explicitly through the use of a jsp-group element.
and
[...] JSP page translated into an implementation class plus deployment information. The deployment information indicates support classes needed and the mapping between the original URL path to the JSP page and the URL for the JSP page implementation class for that page.
So basically, your JSP is translated into a servlet, and a mapping is created from your original JSP page location path to the servlet thus generated.
The JSP is not actually executed. What's executed is the servlet generated from the JSP. You have to realize that JSPs are provided for convenience. If you want to generate HTML from a servlet you have to do a whole bunch of out.write("<html>"); out.write("\r\n"); and so on, for your entire HTML page. It's not only very error prone, but you will go insane doing so. Thus, the option of providing an JSP combined with the things done behind the scene to make it all work.

How to set URL anchor (hash) in servlets?

Simple question! Don't know why Google doesn't know the answer!
In a Java servlet, how can I set the URL anchor (hash) when returning to the user?
The URL anchor is handled by the browser only and never even reaches the server (it's not part of the request).
What this means is that server-side, either in a servlet as you propose or with any other server-side technology (e.g. PHP), you can redirect to an URL which has the URL anchor set, but you cannot check if an URL anchor was provided in the request you are currently processing.
This limitation prevents you from setting the URL anchor while keeping the rest of the URL unchanged, because the server has no way to differentiate between the address with and without the URL anchor.
So, this, you can do: the canonical address to this answer is this
http://stackoverflow.com/a/27988314/4402557
but the server redirects it to this
http://stackoverflow.com/questions/27987762/how-to-set-url-anchor-hash-in-servlets/27988314#27988314
Note that the part of the URL before the anchor is not the same.
In an HTTP servlet, you can achieve this by using the sendRedirect(String) method of the HTTPServletResponse object passed to your service method, for example
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException {
/* ... */
response.sendRedirect("http://example.com/your/url#hash");
}
However, this, you cannot do: redirect this
http://example.com/some/url
to this
http://example.com/some/url#there
As far as the server is concerned, both are the same address, it cannot distinguish between them. That makes it impossible to check if the address was the first (the one without the URL anchor) and redirect conditionally if it is. Redirecting without checking will, of course, create a redirect loop.
However, depending on what it is exactly you are trying to accomplish, even if you cannot do it in your servlet, you can probably achieve it with client-side scripting (i.e. JavaScript). Have a look at the window.location.hash property.
Once I encountered a similar need.
My problem was:
I had two different forms on the same jsp page (one for registrations and one for logging in). The forms were made visible by hashes in urls, i.e. http://myapp.com/auth#login made login form visible and http://myapp.com/auth#signup made signup form visible.
I needed to show the validation errors to the user by reloading the same page, but couldn't navigate to hashes from my servlet.
Here's how I showed validation errors (jsp):
<form method="post" action="authentication">
<c:forEach items="${errorSignupMessage}" var="message">
<div class="error-message">${message}</div>
</c:forEach>
..................................
</form>
and errorSignupMessage was the attribute I passed in through servlet
request.setAttribute("errorSignupMessage", array);
The solution:
Firstly, I created the hidden field in my form that had to contain the needed attributes:
<input type="text" name="ACTION" class="hidden important" value="signup" data-attr="${errorSignupMessage != null ? true : false}"/>
the important thing to look at is the attribute data-attr. As you can see, I set the boolean value on the attribute depending on actions from servlet, i.e. if the errorSignupMessage is null, than the user interacted with another form and if errorSignupMessage exists and is not null, then the current form is the one the user interacted with.
Then I went to javascript and using window.onload event did the data attribute detection and wrote some logic for changing the location.hash value.
var authForms = document.getElementsByClassName('important');
function changeHash() {
for(var i = 0; i < authForms.length; ++i) {
var form = authForms[i];
if (form.value === 'signup' && form.getAttribute('data-attr') === 'true') {
location.hash = '#signup';
} else {
location.hash = '#login';
}
}
}
window.onload = changeHash;
This is how I solved that. Of course, you'll need to adopt all this for your needs, but I think you still get the general idea.
Hope it was helpful!

Duplicating url - Resteasy, Spring, HTML

Spring MVC "duplicates" parts of the URL
I looked at the previous link but the answers did not work and did not seem relevant (unless I'm doing something wrong).
My jboss-web.xml root is "/portal"
I have an jsp doc (with only html in it) that posts to a java controller that authenticates a username and password. The formaction is "portal/index".
<input type="submit" name="submit" value="Submit" onclick="return validation()" formaction="portal/index"/>
The controller's class level path annotation is "portal". The method that I want it to post to has a path annotation "/index".
#Controller
#Path("portal")
public class TheController
{....}
#POST
#Path("/index")
public Response login()
{....}
If the password and username are correct, then the method will forward to home.jsp. Otherwise, it will go back to index.jsp. For some reason, when I submit the form with the incorrect username and password the 1st time, it will go back to "portal/portal/index" (the form will show up) and if I submit it incorrectly a 2nd time, it will go to "portal/portal/portal/index" and the security filter it goes through will return a 404 not found. What is wrong with my set up that is leading to the duplicating URL?
Try using /index in form action, you are using relative path, I think that is causing the issue.
Also remove #path("portal") from your controller.
Update:
Try this in formaction
"${pageContext.request.contextPath}/index"

Forward page from Servlet inside a HTML div

I'm trying to make my page more efficient and so I got the question like below:
Is it possible to forward a new Jsp page with RequestDispatcher into an HTML div from the Servlet?
Like this:
someServlet.java
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException, ServletException {
// do something to send a page to the HTML div in page.jsp
}
page.jsp
<div> <!-- the forwarded page must inside here --> </div>
That's not possible. You can, instead, make an ajax call to your servlet and the servlet may return the necessary data in a format that will help the view to work. An example is by writing the response using JSON format, then handle this JSON response in JavaScript to add the necessary data in your view accordingly.
You could also return a "text/html" response where you write the content of the <div> with the necessary content to just write the HTML response directly in your view. The response used in this approach is easier to use in your view (JSP), but note that will couple your Servlet request to mere HTML responses only.
The decision is up to you.
More info:
How to use Servlets and Ajax?
Do in this way using include instead of forward in page.jsp.
<div> <!-- insert any one --> </div>
Try any one
<jsp:include page="includedPage" />
OR
<jsp:directive.include file="relative url" />
OR
<%# include file="relative url" >
OR
request.getRequestDispatcher("/WEB-INF/jsp/abc.jsp").include(request, response);
If a page is forwarded then it's the responsibility of the forward page to generate the HTML content but in case of include you can combine multiple HTML/JSP/Servlet outputs to generate the final HTML content.
Read more about JSP - The include Directive

doGet and doPost in Servlets

I've developed an HTML page that sends information to a Servlet. In the Servlet, I am using the methods doGet() and doPost():
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
String id = req.getParameter("realname");
String password = req.getParameter("mypassword");
}
public void doPost(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
String id = req.getParameter("realname");
String password = req.getParameter("mypassword");
}
In the html page code that calls the Servlet is:
<form action="identification" method="post" enctype="multipart/form-data">
User Name: <input type="text" name="realname">
Password: <input type="password" name="mypassword">
<input type="submit" value="Identification">
</form>
When I use method = "get" in the Servlet, I get the value of id and password, however when using method = "post", id and password are set to null. Why don't I get the values in this case?
Another thing I'd like to know is how to use the data generated or validated by the Servlet. For example, if the Servlet shown above authenticates the user, I'd like to print the user id in my HTML page. I should be able to send the string 'id' as a response and use this info in my HTML page. Is it possible?
Introduction
You should use doGet() when you want to intercept on HTTP GET requests. You should use doPost() when you want to intercept on HTTP POST requests. That's all. Do not port the one to the other or vice versa (such as in Netbeans' unfortunate auto-generated processRequest() method). This makes no utter sense.
GET
Usually, HTTP GET requests are idempotent. I.e. you get exactly the same result everytime you execute the request (leaving authorization/authentication and the time-sensitive nature of the page —search results, last news, etc— outside consideration). We can talk about a bookmarkable request. Clicking a link, clicking a bookmark, entering raw URL in browser address bar, etcetera will all fire a HTTP GET request. If a Servlet is listening on the URL in question, then its doGet() method will be called. It's usually used to preprocess a request. I.e. doing some business stuff before presenting the HTML output from a JSP, such as gathering data for display in a table.
#WebServlet("/products")
public class ProductsServlet extends HttpServlet {
#EJB
private ProductService productService;
#Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
List<Product> products = productService.list();
request.setAttribute("products", products); // Will be available as ${products} in JSP
request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response);
}
}
Note that the JSP file is explicitly placed in /WEB-INF folder in order to prevent endusers being able to access it directly without invoking the preprocessing servlet (and thus end up getting confused by seeing an empty table).
<table>
<c:forEach items="${products}" var="product">
<tr>
<td>${product.name}</td>
<td>detail</td>
</tr>
</c:forEach>
</table>
Also view/edit detail links as shown in last column above are usually idempotent.
#WebServlet("/product")
public class ProductServlet extends HttpServlet {
#EJB
private ProductService productService;
#Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
Product product = productService.find(request.getParameter("id"));
request.setAttribute("product", product); // Will be available as ${product} in JSP
request.getRequestDispatcher("/WEB-INF/product.jsp").forward(request, response);
}
}
<dl>
<dt>ID</dt>
<dd>${product.id}</dd>
<dt>Name</dt>
<dd>${product.name}</dd>
<dt>Description</dt>
<dd>${product.description}</dd>
<dt>Price</dt>
<dd>${product.price}</dd>
<dt>Image</dt>
<dd><img src="productImage?id=${product.id}" /></dd>
</dl>
POST
HTTP POST requests are not idempotent. If the enduser has submitted a POST form on an URL beforehand, which hasn't performed a redirect, then the URL is not necessarily bookmarkable. The submitted form data is not reflected in the URL. Copypasting the URL into a new browser window/tab may not necessarily yield exactly the same result as after the form submit. Such an URL is then not bookmarkable. If a Servlet is listening on the URL in question, then its doPost() will be called. It's usually used to postprocess a request. I.e. gathering data from a submitted HTML form and doing some business stuff with it (conversion, validation, saving in DB, etcetera). Finally usually the result is presented as HTML from the forwarded JSP page.
<form action="login" method="post">
<input type="text" name="username">
<input type="password" name="password">
<input type="submit" value="login">
<span class="error">${error}</span>
</form>
...which can be used in combination with this piece of Servlet:
#WebServlet("/login")
public class LoginServlet extends HttpServlet {
#EJB
private UserService userService;
#Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");
String password = request.getParameter("password");
User user = userService.find(username, password);
if (user != null) {
request.getSession().setAttribute("user", user);
response.sendRedirect("home");
}
else {
request.setAttribute("error", "Unknown user, please try again");
request.getRequestDispatcher("/login.jsp").forward(request, response);
}
}
}
You see, if the User is found in DB (i.e. username and password are valid), then the User will be put in session scope (i.e. "logged in") and the servlet will redirect to some main page (this example goes to http://example.com/contextname/home), else it will set an error message and forward the request back to the same JSP page so that the message get displayed by ${error}.
You can if necessary also "hide" the login.jsp in /WEB-INF/login.jsp so that the users can only access it by the servlet. This keeps the URL clean http://example.com/contextname/login. All you need to do is to add a doGet() to the servlet like this:
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);
}
(and update the same line in doPost() accordingly)
That said, I am not sure if it is just playing around and shooting in the dark, but the code which you posted doesn't look good (such as using compareTo() instead of equals() and digging in the parameternames instead of just using getParameter() and the id and password seems to be declared as servlet instance variables — which is NOT threadsafe). So I would strongly recommend to learn a bit more about basic Java SE API using the Oracle tutorials (check the chapter "Trails Covering the Basics") and how to use JSP/Servlets the right way using those tutorials.
See also:
Our servlets wiki page
Java EE web development, where do I start and what skills do I need?
Servlet returns "HTTP Status 404 The requested resource (/servlet) is not available"
Show JDBC ResultSet in HTML in JSP page using MVC and DAO pattern
Update: as per the update of your question (which is pretty major, you should not remove parts of your original question, this would make the answers worthless .. rather add the information in a new block) , it turns out that you're unnecessarily setting form's encoding type to multipart/form-data. This will send the request parameters in a different composition than the (default) application/x-www-form-urlencoded which sends the request parameters as a query string (e.g. name1=value1&name2=value2&name3=value3). You only need multipart/form-data whenever you have a <input type="file"> element in the form to upload files which may be non-character data (binary data). This is not the case in your case, so just remove it and it will work as expected. If you ever need to upload files, then you'll have to set the encoding type so and parse the request body yourself. Usually you use the Apache Commons FileUpload there for, but if you're already on fresh new Servlet 3.0 API, then you can just use builtin facilities starting with HttpServletRequest#getPart(). See also this answer for a concrete example: How to upload files to server using JSP/Servlet?
Both GET and POST are used by the browser to request a single resource from the server. Each resource requires a separate GET or POST request.
The GET method is most commonly (and is the default method) used by browsers to retrieve information from servers. When using the GET method the 3rd section of the request packet, which is the request body, remains empty.
The GET method is used in one of two ways:
When no method is specified, that is when you or the browser is requesting a simple resource such as an HTML page, an image, etc.
When a form is submitted, and you choose method=GET on the HTML tag. If the GET method is used with an HTML form, then the data collected through the form is sent to the server by appending a "?" to the end of the URL, and then adding all name=value pairs (name of the html form field and value entered in that field) separated by an "&"
Example:
GET /sultans/shop//form1.jsp?name=Sam%20Sultan&iceCream=vanilla HTTP/1.0 optional headeroptional header<< empty line >>>
The name=value form data will be stored in an environment variable called QUERY_STRING.
This variable will be sent to a processing program (such as JSP, Java servlet, PHP etc.)
The POST method is used when you create an HTML form, and request method=POST as part of the tag. The POST method allows the client to send form data to the server in the request body section of the request (as discussed earlier). The data is encoded and is formatted similar to the GET method, except that the data is sent to the program through the standard input.
Example:
POST /sultans/shop//form1.jsp HTTP/1.0 optional headeroptional header<< empty line >>> name=Sam%20Sultan&iceCream=vanilla
When using the post method, the QUERY_STRING environment variable will be empty.
Advantages/Disadvantages of GET vs. POST
Advantages of the GET method:
Slightly faster
Parameters can be entered via a form or by appending them after the URL
Page can be bookmarked with its parameters
Disadvantages of the GET method:
Can only send 4K worth of data. (You should not use it when using a textarea field)
Parameters are visible at the end of the URL
Advantages of the POST method:
Parameters are not visible at the end of the URL. (Use for sensitive data)
Can send more that 4K worth of data to server
Disadvantages of the POST method:
Can cannot be bookmarked with its data
The servlet container's implementation of HttpServlet.service() method will automatically forward to doGet() or doPost() as necessary, so you shouldn't need to override the service method.
Could it be that you are passing the data through get, not post?
<form method="get" ..>
..
</form>
If you do <form action="identification" > for your html form, data will be passed using 'Get' by default and hence you can catch this using doGet function in your java servlet code. This way data will be passed under the HTML header and hence will be visible in the URL when submitted.
On the other hand if you want to pass data in HTML body, then USE Post: <form action="identification" method="post"> and catch this data in doPost function. This was, data will be passed under the html body and not the html header, and you will not see the data in the URL after submitting the form.
Examples from my html:
<body>
<form action="StartProcessUrl" method="post">
.....
.....
Examples from my java servlet code:
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// TODO Auto-generated method stub
PrintWriter out = response.getWriter();
String surname = request.getParameter("txtSurname");
String firstname = request.getParameter("txtForename");
String rqNo = request.getParameter("txtRQ6");
String nhsNo = request.getParameter("txtNHSNo");
String attachment1 = request.getParameter("base64textarea1");
String attachment2 = request.getParameter("base64textarea2");
.........
.........

Categories

Resources