How do I make getRequest Dispatcher () return null?

[Mike Curwen]

Here's a snip from the API:

The pathname specified may be relative, although it cannot extend outside the current servlet context. If the 
path begins with a "/" it is interpreted as relative to the current context root. This method returns null if the 
servlet container cannot return a RequestDispatcher. 

The servlet receives as part of the URL, the 'next' page in the sequence. ie: servletName?nextPage=uiPage4.jsp

In the servlet code, I retrieve this parameter and do this:

String sendTo = req.getParameter("page");
RequestDispatcher disp = req.getRequestDispatcher("/" + sendTo);
disp.forward(req, res);

But even if sendTo is some page that does not exist, disp will be non-null, and the forward will not fail as a 500 error, but rather a 404 error.

How do I trap the condition where someone tries to play monkey with the URL and requests a different page such as: servletName?nextPage=ImTryingToBeClever.jsp

[Peter den Haan]

Problem is, there is a valid mapping for anything ending in .jsp: the JSP engine servlet. As a workaround, you could in case of .jsps use ServletContext.getResource() to see if the physical .jsp file is there before trying to get the request dispatcher.
- Peter

[Kyle Brown]

Metadata to the rescue, mike! Be sneaky. Instead of:
servletName?nextPage=uiPage4.jsp
use servletName?nextPage=myFoo
Then have a hashmap that connects "abstract" page names to real page names. This is read out of an XML file or a properties file.
So your properties file would have:
myFoo=uiPage4.jsp.
That way you'll know instantly if the page they're requesting isn't a real page -- before you ever get a request dispatcher.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Mike Curwen]

Hi Peter and Kyle,

Thanks for your responses.

Peter, the solution you gave works very nicely. Thanks.

Kyle: I had actually thought of something very much like that. I coded that page way back at the start of development, and it's the only one that still uses the 'nextpage' parameter. I always thought it was kind of 'loose' to put the real page name right out there for all to see on the address bar. Laziness won out though.

Also, at this point, I'm doing minor tweaks and fixes to a 'deployed' application. So I need to furtively make small changes, test on my local instance of Tomcat, wait until everyone goes home, cross my fingers, and redploy on the deployment box.

Operations would have a fit.

[Peter den Haan]

Glad it worked. Kyle's solution would, obviously, have been the one to go for had it been feasible.
- Peter

[Kyle Brown]

Well, there's always the next release
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Peter den Haan]

Yes, the next release *sigh*. Kyle, do you know any devious tricks to persuade management to allocate time for refactoring? No matter how much I insist that it makes good business sense, short-termism rules and applications succumb to entropy well before their time.
- Peter