• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Servlet Mappings and RequestDispatcher inludes

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3695
IntelliJ IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...

https://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
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic