According to the specification:
SRV.3.7.1
Temporary Working Directories
A temporary storage directory is required for each servlet context.
Servlet
containers must provide a private temporary directory per servlet
context, and make
it available via the
javax.servlet.context.tempdir
context attribute. The objects
associated with the attribute must be of type
java.io.File
.
The requirement recognizes a common convenience provided in many
servlet
engine implementations. The container is not required to maintain the
contents of
the temporary directory when the servlet container restarts, but is
required to
ensure that the contents of the temporary directory of one servlet
context is not
visible to the servlet contexts of other web applications running on
the servlet
container.
According to this:
http://archives.real-time.com/pipermail/tomcat-devel/2003-January/046109
.html
Tomcat expects you to maintain your own temporary directory and
only cleans it up if a webapp is undeployed. It does not seem to wipe
out the directory on container restart.
This is actually good news for us because it means you can
store long-term persistent items here. You can even cache images across
container restarts if you know that they are meant to be static (like
the in case of my round corner panel). According to the specs, temp
file cleanup could/should occur within the Servlet destroy() method.
Eelco, are we comfortable with implementing the aforementioned
caching technique? If so, I can file a RFE against it.
Gili
On Tue, 04 Jan 2005 18:40:27 +0100, Eelco Hillenius wrote:
>I guess a temp dir could work fine. And... you don't have to clean up
>temp dirs do you?
>
>Eelco
>
>Gili wrote:
>
>>
>>
>> Eelco, can you please elaborate on what the problem was with JBoss? It
>> seems that me that if we can dump our cache into the tempdir, that is
>> the ideal solution. I suspect existing technologies do the same.
>>
>> Johan, one of the issues we worried about is when these resources are
>> cleaned up. Is the container responsible for clearing them on
>> startup/shutdown or does a cleanup occur on a webapp-basis or never at
>> all?
>>
>> Thanks,
>> Gili
>>
>> --Original Message Text---
>> *From:* Johan Compagner
>> *Date:* Tue, 04 Jan 2005 17:07:41 +0100
>>
>> You can write to disk in a webapplication
>> Use the work dir:
>>
>> ServletContext.getAttribute("javax.servlet.context.tempdir");
>>
>> That will return a File object that points to the work dir for the
>> current webapplication.
>>
>>
>>
>> Gili wrote: Ok, so to rehash some points:
>>
>> 1) Currently we parameterize the image URL on the session ID and
>> parameters used to render the image
>> 2) We write out the image to disk somewhere (although I don't know
>> where, can you elaborate?)
>>
>> My personal requirements are:
>>
>> 1) Render image once per page, not per session or view.
>> 2) Do not expose image parameters if possible. Ideally the URL should
>> read "image<number>.<extension>" and we'll have some lookup table
>> somewhere that maps image creation parameters to image URLs -> reuse
>> the same image if the same parameters are used (server-side).
>>
>> I remember reading about JBoss not giving you write access to
>> the webapp dir (heck, you could be running inside a JAR). I feel this
>> problem related to handling links to images in general, not just
>> dynamically generated ones, if their URL falls under the servlet
>> context path.
>>
>> What we could do (solves all problems I know about) is handle
>> image URLs within the WebApp servlet itself. That is, we never write
>> the images to disk if they're dynamically generated and "cacheDir"
>> (some new property I made up) is not set. For JBoss and others cacheDir
>> will be unset so it'll default to caching in memory. For Tomcat and
>> others, it'll be set to the default temporary directory for the webapp
>> so we'll cache to disk. What will happen is that someone will refer to
>> /MyWebApp/myImage.jpg -- the servlet will recognize that the URL refers
>> to an image, use the appropriate resource location mechanisms -- and
>> stream back the image (whether dynamic or static). And ideally we'd
>> throw in a "image parameters -> image URL" mapping somewhere so we
>> don't have to expose inner details to the HTTP clients.
>>
>> My only concern is that for JBoss, dynamically generated images
>> would be expensive. Still, I don't think we have a choice in such cases
>> if we absolutely cannot write to any directory. What do you think?
>>
>> Gili
>>
>>
>> On Tue, 04 Jan 2005 15:45:50 +0100, Eelco Hillenius wrote:
>>
>> None yet. We're thinking about it.
>>
>> Eelco
>>
>> Gili wrote:
>>
>> I saw a lot of discussion of the various problems and possible
>> solutions but none of them was agreed upon because they each had their
>> own problem. All I know is that in my case the dynamically-generated
>> images should be treated as cacheable because they will not change with
>> clicks (i.e. reference count). What is the proposed solution?
>>
>> Gili
>>
>> On Tue, 04 Jan 2005 13:03:00 +0100, Eelco Hillenius wrote:
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Wicket-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Wicket-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>>
>>
>>
>>
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by: Beat the post-holiday blues
>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>_______________________________________________
>Wicket-develop mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
