-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jukka,
On 5/19/2009 7:58 AM, Jukka Raanamo wrote:
> I was trying to create a Filter that generates the some content as files (if
> required) into the file system and lets the default servlet handle the rest.
Interesting idea.
> However I noticed that if the uri was such that TC would interpret it as
> "static content" like /foobar.html - I would get a 404 on the first request.
> If the uri refers to more dynamic content such as /foobar.jsp - you don't
> get a 404.
Let's see your code...
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain)
> throws IOException, ServletException {
>
> HttpServletRequest httpRequest = (HttpServletRequest) request;
> String uri = httpRequest.getRequestURI();
>
> // assumes not deployed as ROOT
> String relativeURI = uri.substring(uri.indexOf("/", 1),
> uri.length());
Why assume non-ROOT deployment? It's just as easy to use
ServletContext.getContextPath() than it is to arbitrarily chop
characters out of a URI.
> if (relativeURI.equals("/")) {
> relativeURI = "index.jsp";
> } else if (relativeURI.endsWith("/")) {
> relativeURI += "index.jsp";
> }
This seems like a bad idea: why not just leave the URI alone?
> try {
>
> createFile(relativeURI);
>
> if (request.getParameter("include") != null) {
> httpRequest.getRequestDispatcher(relativeURI).
> include(request, response);
What is this "include" parameter? Is that something else for testing?
Why not set up better tests from outside (that use includes) rather than
trying to rig them this way?
> } else if (request.getParameter("forward") != null) {
> httpRequest.getRequestDispatcher(relativeURI).
> forward(request, response);
> } else {
> chain.doFilter(request, response);
> }
You will definitely have to capture the response to the request which is
a non-trivial exercise. I have written code to do this (and more) which
can be found in the archives for this list here:
http://marc.info/?l=tomcat-user&m=123603411023864&w=2
> private void createFile(String relativeURI) throws Exception {
> String webAppDir = filterConfig.getServletContext().getRealPath("");
> File contentFile = new File(webAppDir, relativeURI);
>
> contentFile.getParentFile().mkdirs();
>
> FileWriter writer = new FileWriter(contentFile);
This is going to be a problem. You should store your files somewhere
other than the webapp directory or things are going to be a real headache.
> writer.write("<html><body>" +
> "<pre>" +
> "Current Servlet time: " + new Date() +
> "<br/>" +
> "Current JSP time: <%=new java.util.Date()%><br/>" +
> "</pre>");
That doesn't seem to capture the server's response.... or are you just
trying to see if your technique will work before you implement everything?
It appears that you are trying to capture content, write a file into the
webapps directory, and then have the DefaultServlet serve that content
for you. That's not going to work because of two things:
1. Webapp deployment sometimes doesn't allow you write to the webapps
(or other deployment) directory
2. The DefaultServlet does its own caching of directory information
(which I find irritating, honestly) so that newly-created files
are not always (or ever?) able to be served by it. You will probably
have to do your own interception of the request and serve the bytes
yourself. You have already seen that disabling caching makes this
work.
Finally, you are messing with the URI by changing "/" to "index.jsp" and
other foolish things like that. If you need to make-up a name for the
file, make up something that is used solely for the filename, instead of
re-writing the URI that you use for request dispatching.
Making those changes will surely help.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkolXksACgkQ9CaO5/Lv0PBSKgCgimJQlCRi6eab/xsEfVE/3GrC
OQMAn2wBeSJzFWdJEL0nw+oG/IyZsO5J
=M+P4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
