tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jraanamo <jukka.raan...@gmail.com>
Subject Re: Caching of static content
Date Thu, 11 Jun 2009 06:22:52 GMT



Christopher Schultz-2 wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> 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.
> 
> 
> 1) This is just a mock Filter to reproduce the behaviour. I guess I should
> have mentioned this but I though I that the code was a clear statement of
> this - at least the createFile -method if nothing else.
> 
> 
> 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?
> 
> 2) See section 1. above and my initial test uri's, e.g.
> /somenewdirectory/?forward=1 - this was to easily test if forwarding and
> including behaves differently.
> 
> 
> 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.
> 
> 3) Like said - a demo.
> 
> 
> 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?
> 
> 4) Yes! Or else I've written an Filter that really does not do anything
> smart - would not be the first time though. 
> 
> 
> 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:
> 
> 5) Fairly close to my initial problem description: 
> 
> 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.
> 
> 
> 1. Webapp deployment sometimes doesn't allow you write to the webapps
>    (or other deployment) directory
> 
> 6) Now this is a good point but I don't know how this is restricted else
> than by the file system. I usually only work with Tomcat - maybe there are
> other restrictions with other servlet containers - do you know?
> 
> 
> 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.
> 
> 7) Yes, I sort of figured this out which is why I posted the question in
> the first place - instead of starting to read through the DefaultServlet
> code (which I should have done). And my badly formulated question: 
> 
>  how to force TC to check if file exists in real time?
> 
> should have stated how to disable DefaultServlets internal caching
> 
> And the reason why I did not want to write the content into the response
> stream in the first place was - if you noticed - the content was JSP
> files.  I really wanted the DefaultServlet to handle the file processing
> and keep the Filter non intrusive of what ever else was in the webapp
> processing chain (e.g. other Filters like Sitemesh etc).
> 
> 
> 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.
> 
> 8) I thought we agreed there was no name calling!? Playing around with
> URI's can be a lots of fun - especially if you think of those three small
> letters: S.E.O.
> 
> 9) To sum it up. I only wanted to know how to get around the internal
> caching of dynamic content what comes to DefaultServlet. And as "Lyallex"
> asked me, my work-around was to generated the files outside the servlet
> container and have Tomcat just serve them. Much cleaner solution but also
> not so flexible what comes to more "personalized" content.
> 
> 
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Caching-of-static-content-tp23614901p23975925.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message