<Gili presses the reset button>
Ok, it seems either I was misunderstanding what was being said
or you misunderstood me so lets get back to the beginning.
I am saying that the Wicket servlet should handle image
requests and decide whether or not to retrieve them from the static
image store (i.e. normal paths) or dynamic image store (i.e. tempdir
cache directory). I don't agree/understand why Eelco says that it is
not possible and that the Webserver needs to do something on our
behalf...?
Gili
On Tue, 04 Jan 2005 23:31:32 +0100, Johan Compagner wrote:
>Why should the server have direct access to it?
>How do you think that currently static resources that are served by
>tomcat/resin or jetty? Through a servlet!
>It is just a way that you set the right headers AND return the right
>date in the getLastModified() method of a servlet..for a specific request..
>
>I just made a new Servlet that servers jars/zips for java webstart. So
>that i can look how JavaWebstart wants the jars (what it supports)
>so that i can use the super new compression 1.5 has now (pack200). So
>if it supporst it i return a jar:
>
>jarname.jar.pack.gz file instead of a jarname.jar
>
>Pack200 is by the way very good in compressings jars with class data..
>in the default configuration a jar or 1.5MB crumbles to 500KB
>
>examples of the lastmodified:
>
>protected long getLastModified(HttpServletRequest request)
> {
> String servletPath = request.getServletPath();
> File originalFile = new
>File(this.getServletContext().getRealPath(servletPath));
> if(originalFile.exists())
> {
> return originalFile.lastModified();
> }
> return -1;
> }
>in the doGet:
>
> if ( request.getProtocol().equals("HTTP/1.0") ) //$NON-NLS-1$
> {
> response.setHeader( "Pragma", "no-cache" ); //$NON-NLS-1$
>//$NON-NLS-2$
> response.setDateHeader( "Expires", ageTime ); //$NON-NLS-1$
> }
> else if (request.getProtocol().equals("HTTP/1.1") ) //$NON-NLS-1$
> {
> response.setHeader( "Cache-Control", "max-age=" + ageTime
>); //$NON-NLS-1$ //$NON-NLS-2$
> }
>
>response.setContentLength(Integer.parseInt(Long.toString(originalFile.length())));
> response.setDateHeader("Last-Modified",
>originalFile.lastModified()); //$NON-NLS-1$
>
>set the same date in the header.
>
>Then everything is cached and a HEAD lookup of the browser will get the
>lastModified date
>and knows that it doesn't have to do a full GET call.
>
>johan
>
>Eelco Hillenius wrote:
>
>> Using the temp dir actually is not a solution here, because:
>> 1. in order to really work, your web(app) server should have direct
>> acces to it. As this is not the case when working with the temp dir
>> (at least not without additional configuring), the requests will go
>> through Servlets. And to have maximum gain, you want your server to
>> regconize that the client is requesting a static resource, not a
>> dynamic servlet.
>> 2. the start of the solution would be:
>> a. to get rid of the constantly changing urls (though this might
>> not be possible as the rendercount is important for our stale page
>> tracking);
>> b. set an expiration header (e.g. to epoch) for selected resources.
>>
>> I guess if 2. is solved, we won't be needing one, do we?
>>
>> Eelco
>>
>> Jonathan Locke wrote:
>>
>>> 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
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
