[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-user
Subject:    Re: Autoreload and WebappLoader
From:       Daniel Dekany <ddekany () freemail ! hu>
Date:       2003-08-17 21:26:51
[Download RAW message or body]

Sunday, August 17, 2003, 10:29:57 AM, Claude Brisson wrote:

> > isSourceModified and getLastModified are basically no-ops for the WebappLoader
> 
> the main problem here is that the WebappLoader accesses resources via
> the servlet api (to work as well with exploded resources as with war
> files), and that the actual servlet api doesn't give us any date/time
> information on files. Maybe that would be the kind of feedack to give
> to w3c folks.

It's possible to get the last modification time of servlet resources:
You can get an java.net.URL with ServletContext.getResource(path). Then,
you can create an java.net.URLConnection with URL.openConnection(), and
URLConnection has a getLastModified() method.

> A potential workaround would be to reload all resources in dev mode, and not to \
> reload any one in production mode (except on some 'reload' signal manually \
> generated, to avoid restarting ?)

BTW, this reminds me of a practical issue with the method I said above.
At least Tomcat 4.1 is lazy about monitoring the changes of the
resources. That is, you change the file, but then if you access it
through the servlet resource API, it will sometimes pretend *forever*
that the file was not changed... quite annoying. The workaround I did
for this is that I try to access the resource as File: Use
ServletContext.getRealPath(path), and if it is successful, then use the
File directly, rather than the servlet resource API.

-- 
Best regards,
 Daniel Dekany



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]