On Mon, 14 Mar 2005, Sylvain Vieujot wrote:
Instead of setting the last-modified header, I was working on including the jar build version (in fact, it's hash) in the URL, and setting a long (default one week) expiry. So, all the content is cached, and when you change your MyFaces jar, the URL is different. I think it would be better, as the browser will not even query for the last-modified header, and a query will be saved. Also, I don't know if we can get the last modified date from a file that's in a jar.
Any comment with this approach ?
We used this approach in a recent release of a large web app at my day job. It works out really well, because the browser only ever asks for a resource once until you upgrade to a later version, at which point the browser automatically gets the latest version, again only once. Very effective.
-- Martin Cooper
As stated on a previously, the code is ready, I just need to get the implementation version. Right now, AddResource.class.getPackage().getImplementationVersion() return null.
On Sun, 2005-03-13 at 21:06 -0800, Korhonen, Kalle wrote:
-----Original Message----- From: Oliver Rossmueller [mailto:[EMAIL PROTECTED] Subject: Split (or kill) Extensions filter I'm no longer willing to pay the runtime penalty ExtensionFilter adds to an application (javascript files loaded over and over again, in-memory buffering of the complete response) just for the benefit of 10 minutes of saved developer time for adding the javascript stuff to the header of any jsf page.
The only problem as I can see with the extensionsFilter is that it doesn't currently send the last-modified header when sending a resource. I've been meaning to patch it when I have some time for that, but I'm more than happy if somebody else fixes it before I have a chance. That saved 10 mins for every JSF developer quickly adds up and I strongly believe that 10 mins is worth saving.
So my plan is to split up ExtensionFilter to MultipartFilter (in the form it was before ExtensionFilter was introduced) and ExtensionFilter (just dealing with extensions stuff). Actually I would like to drop the extensions stuff completely as I don't see any benefit in having this kind of filter at hand. We could create a myfaces-resources.jar instead where we place all the image and javascript resources so it's easy to add all the resources to your war file by just adding a zipfileset tag to your build file. Comments? Objections?
Personally, I think ExtensionsFilter is a pretty clever way of loading packaged resources. Please consider evolutionary versus revolutionary approach in this case as well.
Kalle
