wood burning stoves 2.0*
The moose likes Servlets and the fly likes Servlet Mappings and RequestDispatcher inludes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Servlets
Bookmark "Servlet Mappings and RequestDispatcher inludes" Watch "Servlet Mappings and RequestDispatcher inludes" New topic
Author

Servlet Mappings and RequestDispatcher inludes

Brian Hart
Greenhorn

Joined: Jun 23, 2002
Posts: 5
I have a servlet mapping to prevent direct access to a given directory of static html that is used to contain html 'snippets' that cannot be accessed durectly, but must be included in the context of the overall site. The Servlet Mapping is:
<servlet-mapping>
<servlet-name>ContentServlet</servlet-name>
<url-pattern>cms_published/*</url-pattern>
</servlet-mapping>
Now, in the ContentServlet's doGet(), If I have logic to correctly include the requested html document I get a stackoverflow because the include() call hits my servlet-mapping, fires this logic again in an infinite loop. I was hoping the servlet Mappings would not be applied when processing an include().
Below is sample request dispatcher code within the ContentServlet:
RequestDispatcher d1 = getServletContext().getRequestDispatcher("/cms_published/assessments/as_3_2_1.html");
try{
//this creates the infinite loop from the servlet mapping back to this logic. and stack overflow.
d1.include(request, response);
}catch(Exception e)
{
out.println(e);
}
Any suggestions on how to correctly implement this would be greatly appreciated.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

The problem (as I see it) is that the pattern that invokes your gatekeeper is the same as the pattern to get to the stuff being guarded.. and when you try to include that stuff... alas! another gatekeeper!

My first instinct was to tell you to just rename your directory to something else, and then your include would not invoke the keeper again. But then your directory would be wide open to browsing independent of the keeper.

So I sorta kinda figured out a way to do it, but it's really a lot of hoop jumping. My advice is to use your webserver configuration to make a directory non-browsable. But the server-side would still see it, and all will be well.
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
If the included resources do not do any Request processing (i.e, they are staitc HTML pages, images etc., and not Servlets, or JSPs) then, instead of "include"-ing them, use either "getResourceAsStream" or "getResource".
-GB.
Brian Hart
Greenhorn

Joined: Jun 23, 2002
Posts: 5
This logic will be hit quite often, is there any best practices here? It is static html, so is there a way to leverage the application server in some fashion to not assume it needs to keep reading in these files after the first time.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

If the content is indeed static, using the 'static include' is your "best practice".

That is, only if what's being included is static, and not just the content itself (which perhaps isn't your case?). Read this link, my two posts towards the bottom...

http://www.coderanch.com/t/351594/Servlets/java/passing-parameters-included-jsp-file

As for leveraging the app server... I worked with iPlanet app server a bit, and there was a way to get it to cache pages, not only based on requested page, but on the parameters sent to that page...

Two example URLS:
mysecuredpage?group=admin
and that results in a file that includes resources 1,2,3 and 4
mysecuredpage?group=user
which resulted in the inclusion of resources 1 and 2 only

One the second request for either of these URLS, iPlanet would recognize it had already satisfied this request once before, and you could set it to serve the cached copy.

If you need finer-grained control over this than your app server provides (perhaps the URI has no defining parameters), I suppose some sort of application level caching could be done. Someone else suggested using regular FileIO and reading in the contents. You could then cache this 'blob' of text for 'faster' retrieval.

But you'd have to convince yourself that your cache would be more performant that the code used by the app server to do dynamic includes. This includes issues like:
will java file i/o be faster than potential native methods used by the app server?
will the search time in your cache be faster than the app server finding a file on the file system?
even better.. maybe the app server already caches some items. Would you be doing an end-run around this mechanism?
will the memory footprint of your cache destroy any gain you might realize?
how do you manage the cache size?

You paid $$$ for your server... can you assume it will do a better job?
[ February 27, 2003: Message edited by: Mike Curwen ]
Brian Hart
Greenhorn

Joined: Jun 23, 2002
Posts: 5
Your response isn't within the context of the SERVLET-MAPPING problem in the first post. any attempts to use an include call from the RequestDispatcher, fires the mapping logic causing an infinite loop. I am dissapointed that the server doesn't distinguish the HTTP request from the browser for the resource (fire the mapping) verse a RequestDispater.include() (don't fire the mapping.
Any thoughts.
 
GeeCON Prague 2014
 
subject: Servlet Mappings and RequestDispatcher inludes