yeah, but this isn't a long term solution. we ought to be able to return
images that get cached... even dynamically generated ones. there ought
to be a way to fudge the rendercount stuff so the browser will cache
images.
On Tue, 4 Jan 2005, Johan Compagner wrote:
> 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
