jsps not serving from context root in netbeans server

[Dundonald]

I've just started using Netbeans 5.5 packaged with the sun java
application server 9. I run a web app with a context root of for the
sake of example "test", the default page set in web.xml to run at
startup is index.jsp, that is served fine in that index.jsp simply
redirects to a servlet call. The servlet executes fine, but any
resultant request for a jsp seems to be requested outside of the
context root instead of using the context root and a 404 is returned.
So it's obvious that the server is looking in the wrong place for the
JSP.

The flow of my application except for startup is when a link is
clicked always a servlet does some execution and then responds with a
redirect to a jsp for screen display.

To demonstrate:

Startup ->
http://localhost:8080/test/index.jsp (served ok) -> redirects to
http://localhost:8080/test/someservlet -> executes ok redirects to
http://localhost:8080/nextjsp.jsp

So questions are:

1. why does the first jsp (index.jsp) serve fine using the context
root and then
2. with any subsequent request the request for the jsp does not use
the context root?

Note that if I manually type in http://localhost:8080/test/nextjsp.jsp
it works.

Also note that in the web xml all the servlets have mappings and only
index.jsp is listed as the welcome jsp. Surely not every JSP has to
be listed in the web xml. I've had web apps in WSAD that didn't
require this.

And final note is that if I change the context root to / (well
actually netbeans doesn't let just / to be entered as context root so
the field has to be left as blank) a similar problem happens, because
for some reason, the server decides to use a context root after all of
"web". I don't understand that one either.

 

[Dundonald]

I've just started using Netbeans 5.5 packaged with the sun java
application server 9. I run a web app with a context root of for the
sake of example "test", the default page set in web.xml to run at
startup is index.jsp, that is served fine in that index.jsp simply
redirects to a servlet call. The servlet executes fine, but any
resultant request for a jsp seems to be requested outside of the
context root instead of using the context root and a 404 is returned.
So it's obvious that the server is looking in the wrong place for the
JSP.

The flow of my application except for startup is when a link is
clicked always a servlet does some execution and then responds with a
redirect to a jsp for screen display.

To demonstrate:

Startup ->http://localhost:8080/test/index.jsp(served ok) -> redirects tohttp://localhost:8080/test/someservlet-> executes ok redirects tohttp://localhost:8080/nextjsp.jsp

So questions are:

1. why does the first jsp (index.jsp) serve fine using the context
root and then
2. with any subsequent request the request for the jsp does not use
the context root?

Note that if I manually type inhttp://localhost:8080/test/nextjsp.jsp
it works.

Also note that in the web xml all the servlets have mappings and only
index.jsp is listed as the welcome jsp. Surely not every JSP has to
be listed in the web xml. I've had web apps in WSAD that didn't
require this.

And final note is that if I change the context root to / (well
actually netbeans doesn't let just / to be entered as context root so
the field has to be left as blank) a similar problem happens, because
for some reason, the server decides to use a context root after all of
"web". I don't understand that one either.

Sorry about the duplicate, not sure what happened with google groups.

Any help appreciated. Thanks.

 

[Lew]

I've just started using Netbeans [sic] 5.5 packaged with the sun [sic] java [sic]
application server 9. I run a web app with a context root of for the
sake of example "test", the default page set in web.xml to run at
startup is index.jsp, that is served fine in that index.jsp simply
redirects to a servlet call. The servlet executes fine, but any
resultant request for a jsp [sic] seems to be requested outside of the
context root instead of using the context root and a 404 is returned.
So it's obvious that the server is looking in the wrong place for the
JSP.

You fail to show the code for how you're navigating to the view JSP.

When you say "redirect", you probably should be saying "forward". The servlet
should use the RequestDispatcher forward() method to get to the JSP.

Because you're using redirect instead of forward().

Sure.

WSAD, JBuilder, NetBeans, it doesn't matter.

No, you don't need to list every JSP.

And final note is that if I change the context root to / (well
actually netbeans [sic] doesn't let just / to be entered as context root so

'/' is not a good context root for an application.

Sorry about the duplicate, not sure what happened with google groups.

Google Groups sucks.

 

[Dundonald]

I've just started using Netbeans [sic] 5.5 packaged with the sun [sic] java [sic]
application server 9. I run a web app with a context root of for the
sake of example "test", the default page set in web.xml to run at
startup is index.jsp, that is served fine in that index.jsp simply
redirects to a servlet call. The servlet executes fine, but any
resultant request for a jsp [sic] seems to be requested outside of the
context root instead of using the context root and a 404 is returned.
So it's obvious that the server is looking in the wrong place for the
JSP.

You fail to show the code for how you're navigating to the view JSP.

Yeah good point, apologies, here it is:

private void sendResponse(HttpServletResponse resp) throws IOException
{
resp.sendRedirect( resp.encodeURL(getJspNameToSendInResponse()) );
}

When you say "redirect", you probably should be saying "forward". The servlet
should use the RequestDispatcher forward() method to get to the JSP.

See code above, by redirect I mean a response.redirect. I'm unsure of
the RequestDispatcher forward() method. What I'm so curious about is
why the response redirect method works in WSAD and even when I deploy
a war to tomcat, but in this particular instance it doesn't. Unless I
have missed something when copying across my code from the WSAD
workspace in to a fresh new netbeans project. I've only just started
using netbeans for the first time.

Because you're using redirect instead of forward().

Is this an issue after my clarification and code above? If so I'd
like to understand why it works when I deploy to tomcat from a WSAD
workspace.

WSAD, JBuilder, NetBeans, it doesn't matter.

No, you don't need to list every JSP.

Good. Thanks.

And final note is that if I change the context root to / (well
actually netbeans [sic] doesn't let just / to be entered as context root so

'/' is not a good context root for an application.

Sorry about the duplicate, not sure what happened with google groups.

Google Groups sucks.

Useful and convenient though, I can access usenet wherever I am.

Thanks for your help.

 

[Chris ( Val )]

I've just started using Netbeans [sic] 5.5 packaged with the sun [sic] java [sic]
application server 9. I run a web app with a context root of for the
sake of example "test", the default page set in web.xml to run at
startup is index.jsp, that is served fine in that index.jsp simply
redirects to a servlet call. The servlet executes fine, but any
resultant request for a jsp [sic] seems to be requested outside of the
context root instead of using the context root and a 404 is returned.
So it's obvious that the server is looking in the wrong place for the
JSP.

You fail to show the code for how you're navigating to the view JSP.

Yeah good point, apologies, here it is:

private void sendResponse(HttpServletResponse resp) throws IOException
{
resp.sendRedirect( resp.encodeURL(getJspNameToSendInResponse()) );
}

Looks like some custom method that no one would
have a clue about its internals

See code above, by redirect I mean a response.redirect. I'm unsure of
the RequestDispatcher forward() method. What I'm so curious about is
why the response redirect method works in WSAD and even when I deploy
a war to tomcat, but in this particular instance it doesn't. Unless I
have missed something when copying across my code from the WSAD
workspace in to a fresh new netbeans project. I've only just started
using netbeans for the first time.





Is this an issue after my clarification and code above? If so I'd
like to understand why it works when I deploy to tomcat from a WSAD
workspace.

[snip]

I think Lew might have been referring to something like this instead:

String address = "/test/nextjsp.jsp";
RequestDispatcher dispatcher =
request.getRequestDispatcher( address );
dispatcher.forward( request, response );

 

[Lew]

How about you read the Javadocs on it, then? My purpose in mentioning it was
so that you would RTFM.

 

[Dundonald]

Dundonald wrote:
I've just started using Netbeans [sic] 5.5 packaged with the sun [sic] java [sic]
application server 9. I run a web app with a context root of for the
sake of example "test", the default page set in web.xml to run at
startup is index.jsp, that is served fine in that index.jsp simply
redirects to a servlet call. The servlet executes fine, but any
resultant request for a jsp [sic] seems to be requested outside of the
context root instead of using the context root and a 404 is returned.
So it's obvious that the server is looking in the wrong place for the
JSP.
You fail to show the code for how you're navigating to the view JSP.

Yeah good point, apologies, here it is:

private void sendResponse(HttpServletResponse resp) throws IOException
{
resp.sendRedirect( resp.encodeURL(getJspNameToSendInResponse()) );
}

Looks like some custom method that no one would
have a clue about its internals

Yeah sorry, my custom method But I guessed it was straight forward
enough to understand ... accepts a HTTP response object, obtains the
JSP name that is ready to send back to the browser after some servlet
processing, encodes the URL for session state etc if required and
sends it back by the redirect method.

See code above, by redirect I mean a response.redirect. I'm unsure of
the RequestDispatcher forward() method. What I'm so curious about is
why the response redirect method works in WSAD and even when I deploy
a war to tomcat, but in this particular instance it doesn't. Unless I
have missed something when copying across my code from the WSAD
workspace in to a fresh new netbeans project. I've only just started
using netbeans for the first time.

Is this an issue after my clarification and code above? If so I'd
like to understand why it works when I deploy to tomcat from a WSAD
workspace.

[snip]

I think Lew might have been referring to something like this instead:

String address = "/test/nextjsp.jsp";
RequestDispatcher dispatcher =
request.getRequestDispatcher( address );
dispatcher.forward( request, response );

Interesting how you have essentially hard coded the "test" context
root into the address though, because essentially that would mean if
anyone changed the context root of an app (in a shared dev of course)
then hard coded is not too good. I'm wondering if there is a better
way to dynamically put in the context root, if it's required of course?

 

[Lew]

Yeah sorry, my custom method But I guessed it was straight forward
enough to understand ... accepts a HTTP response object, obtains the
JSP name that is ready to send back to the browser after some servlet
processing, encodes the URL for session state etc if required and
sends it back by the redirect method.

The trouble with the redirect, compared to a forward, is that redirect loses
the request data and forces another round-trip to the client. A forward
preserves the request and happens server side.

 

[Dundonald]

The trouble with the redirect, compared to a forward, is that redirect loses
the request data and forces another round-trip to the client. A forward
preserves the request and happens server side.

Yes I've been doing some googling and RTFMing as you advised (well
I was doing that anyway) but I must admit despite reading the API and
a couple sites found on google so far it's still not clear how use of
this method can help with maintaining context root. I may well be
missing something.

 

[Lew]

Yes I've been doing some googling and RTFMing as you advised (well
I was doing that anyway) but I must admit despite reading the API and
a couple sites found on google so far it's still not clear how use of
this method can help with maintaining context root. I may well be
missing something.

My main points have to do with keeping the request and avoiding the round trip
to the client.

HttpServletResponse.sendRedirect() tells us that, "f the location is
relative without a leading '/' the container interprets it as relative to the
current request URI. If the location is relative with a leading '/' the
container interprets it as relative to the servlet container root."

The leading '/' moves the redirect out of the context. I'm thinking that the
"current request URI" includes not only the application context root but the
specific resource handling the request. You might need to prefix the redirect
URL with "../".

However, I will say that most of what people want to do with a redirect is
better handled by the forward mechanism.

 

[Dundonald]

Yes I've been doing some googling and RTFMing as you advised (well
I was doing that anyway) but I must admit despite reading the API and
a couple sites found on google so far it's still not clear how use of
this method can help with maintaining context root. I may well be
missing something.

My main points have to do with keeping the request and avoiding the round trip
to the client.

HttpServletResponse.sendRedirect() tells us that, "f the location is
relative without a leading '/' the container interprets it as relative to the
current request URI. If the location is relative with a leading '/' the
container interprets it as relative to the servlet container root."

The leading '/' moves the redirect out of the context. I'm thinking that the
"current request URI" includes not only the application context root but the
specific resource handling the request. You might need to prefix the redirect
URL with "../".

However, I will say that most of what people want to do with a redirect is
better handled by the forward mechanism.

OK I've been doing some more reading of the APIs. I now understand
completely. The forward vs a redirect aside (as in the fact that the
redirect sends a response back to the browser to then send another
request for a specific resource), I now also understand about the
context root.

I have done some digging and a response.sendRedirect is still possible
IF the request.getContextPath() method is used to suppliment the jsp
name so for example:

resp.sendRedirect( resp.encodeURL( req.getContextPath() +
getJspNameToSendInResponse() ) )

or and as you have suggested I have also got it working with:

getServletContext().getRequestDispatcher(getJspNameToSendInResponse()).forward(getCurrentHttpServletRequest(),
resp);

where the current context of the current servlet is used to obtain the
dispatcher and then forward on.

Thanks!

So the only question I have now is, I'm assuming of course that the
encodeURL as used in the sendRedirect example is negligible in the
request dispatcher forward case?

 

[Lew]

getServletContext().getRequestDispatcher(getJspNameToSendInResponse())
.forward(getCurrentHttpServletRequest(),resp);

From what method are you making this call?

 

[Dundonald]

From what method are you making this call?

The code above is within a private method that is called by doPost,
same method as posted in my code earlier. Except in the test I was
lazy and used an already existing getCurrentHttpServletRequest()
method to pull in the request object instead of updating the method
signature to cater for (req, resp).

 

[Lew]

The code above is within a private method that is called by doPost,
same method as posted in my code earlier. Except in the test I was
lazy and used an already existing getCurrentHttpServletRequest()
method to pull in the request object instead of updating the method
signature to cater for (req, resp).

Thank you.

 

[Chris ( Val )]

[snip]

String address = "/test/nextjsp.jsp";
RequestDispatcher dispatcher =
request.getRequestDispatcher( address );
dispatcher.forward( request, response );

Interesting how you have essentially hard coded the "test" context
root into the address though, because essentially that would mean if
anyone changed the context root of an app (in a shared dev of course)
then hard coded is not too good. I'm wondering if there is a better
way to dynamically put in the context root, if it's required of course?

I agree, but my intent was to show you how to use the
RequestDispatcher
to forward to another page, and not show you how to obtain your values
dynamically.

Also note, that at the time I posted my response to you, how was I to
know that you were not already obtaining the values dynamically from
your deployment descriptor?

Anyway, it is not difficult to obtain the values you're after.

You just need to investigate the API for 'ServletContext', and
the methods it exposes.