atom feed30 messages in Forum: JAWR support for images
FromSent OnAttachments
Jordi SellésMar 9, 2009 10:44 am 
Matt RubyMar 9, 2009 11:09 am 
Matt RubyMar 9, 2009 11:21 am 
Jordi SellésMar 9, 2009 11:24 am 
Matt RubyMar 9, 2009 11:44 am 
Jordi SellésMar 9, 2009 1:32 pm 
ibrahim CHAEHOIMar 9, 2009 2:28 pm 
Jordi SellésMar 9, 2009 3:49 pm 
ibrahim CHAEHOIMar 11, 2009 4:30 pm 
Jordi SellésMar 12, 2009 2:28 am 
ibrahim CHAEHOIMar 17, 2009 2:27 pm 
Jordi SellésMar 17, 2009 4:07 pm 
ibrahim CHAEHOIMar 18, 2009 1:13 pm 
ibrahim CHAEHOIApr 5, 2009 1:40 pm 
Jordi SellésApr 5, 2009 4:19 pm 
Matt RubyApr 5, 2009 4:30 pm 
ibrahim CHAEHOIApr 6, 2009 11:53 am 
Jordi SellésApr 6, 2009 1:37 pm 
ibrahim CHAEHOIApr 25, 2009 10:24 am 
ibrahim CHAEHOIApr 26, 2009 4:33 am 
Jordi SellésApr 27, 2009 12:49 am 
Jordi SellésApr 27, 2009 9:58 am 
ibrahim CHAEHOIApr 27, 2009 1:32 pm 
ibrahim CHAEHOIMay 7, 2009 3:40 pm 
Jordi SellésMay 8, 2009 3:06 am 
Jordi SellésMay 8, 2009 3:18 am 
ibrahim CHAEHOIMay 8, 2009 3:49 am 
Jordi SellésMay 8, 2009 4:02 am 
ibrahim CHAEHOIMay 8, 2009 4:07 am 
Jordi SellésMay 8, 2009 5:29 am 
Subject:RE: Forum: JAWR support for images
From:Jordi Sellés (
Date:Mar 9, 2009 3:49:29 pm

Hi Ibrahim:

So at compile time, we will generate a folder for the images with modified names and we will save in an hash the mapping between the real and the modified path. This map will be saved somewhere perhaps directly in the

That's something I've been wondering myself: how to save the bundle mappings and
hashes found in compile time to retrieve in run time. I didn't think of using
the properties file, might be a good idea although I don't know how that would
work with Grails. Another though I had was to use some sort of serialized object
to deserialize in run time, but sounds a bit too hacky (opinions?). Yet another
option is to use an embedded database which I think is included with the JVM
from JDK 5 forward but of course that breaks java 1.4 compatibility unless extra
dependencies are added.

So I'm not sure what would be the best way to achieve this. We'd need to store
at least the bundle member names (since they can be used in tags instead of the
bundle id), and the hash. Possibly something else, I can't remember right now.
Maybe the properties file could be used for this purpose, at least sounds less
complicated that serializing or using an embedded database, but still lots of
data to store in such format. Any brilliant idea from anyone to achieve this
super nicely?

As for what features go first, I think it's the other way around, I'd first turn
the current features into compile time processing, then add images support. It
is just as importan to compress/postprocess javascript and CSS in compile time
as it is with images. Some people favor alternatives to Jawr because it doesn't
work in compile time so seems a needed step to improve acceptance of the

Finally, the maven task: a greek friend called Andreas has already made a maven
plugin for Jawr: It is kind of hacky, since it creates a mock ServletContext to make Jawr believe
it is in a running server. I contacted him and he showed willingness to update
his mojo once we have a working compile time component. I don't know if he will
actually do it (after all, no contract was signed), but it would be rude if we
just did it without asking him first. Still, thanks for the offer and indeed
I'll count on your help for that.

One final note: if anyone decides to start working on a compile time component,
I was thinking that it would be best to create a separate branch for that, since
I guess it's going to take architectural changes so we better keep it apart.
Besides we might make a couple minor releases before 3.0.

I must say it's great to count on your help guys, it felt lonely in this
project! Jordi

Date: Mon, 9 Mar 2009 22:28:17 +0100 From: To: Subject: Re: Forum: JAWR support for images


I would just like to clarify how we plan to handle the image caching.

The user will define a bundle like jawr.img.bundle= /img .... In this property we define all images that JAWR will handle.

So at compile time, we will generate a folder for the images with modified names and we will save in an hash the mapping between the real and the modified path. This map will be saved somewhere perhaps directly in the

So we will be able to generate the right HTML image tag, pointing to right URL (in the web application or using the CDN).

We could work on the compile-time Jawr step by step: - if the first need is the image handling, we could focus on this need first, and then enhance the code to handle all JAWR features, and have a full compile time JAWR.

I could work on the maven plugin for this.

Just a word for Matt :Congratulations for your child!!! Take care of you and your family.


PS : I will probably add the image caching for classpath images this week end. I would probably use something like the cache buster algorithm define in "juicer".

On Mon, Mar 9, 2009 at 9:33 PM, Jordi Sellés <> wrote:

Hey Matt, Thanks for taking up an issue, good luck with that.

About images, it is true that in production the usual is to serve them from a separate host. This again leads to priority number one: compile time Jawr. If we were able to create an actual hash in the file names during build time, users could upload these to the images server and let the tags generate the proper link. This also goes for people using a CDN to serve javascript and CSS, they can build a dir structure and upload it to the CDN, then use the tags to generate the links. Finally, users without a separate server for images would benefit from the regular header/caching techniques already used by Jawr.

Anyway, this is all small talk compared with having a child. Best luck and congratulations!

________________________________ Date: Mon, 9 Mar 2009 12:44:18 -0600 From: To: Subject: Re: Forum: JAWR support for images

OK, I'm glad to know where you see things going. I'll take a look at the issue tracker. I have a hard time wrapping my head around the image support. Many applications host their images outside of the application server. I know we have a two apache servers that handle much of our image serving. I'm not sure how to determine the image version or hash on the fly without making a separate http call for the image at run time. I guess I need some help understanding how jawr will determine the version of an image and put that information into the img tag. -Ruby PS: I'm expecting my first child shortly (this week or next). I'll be out of the office for at least two weeks. On Mon, Mar 9, 2009 at 12:25 PM, Jordi Sellés <> wrote:

Well, I always thought that images support would be a natural addition to Jawr, especially if CSS images were versioned by a post processor. And of course, generating sprites comes to mind as well. In my 'mental roadmap' which I guess I should share with this list, there are two things that are a must for Jawr 3.0 (note we still may make two point releases before that). These two thing are:

1. Compile time running of Jawr. Sound easy until you think about certain generators such as DWR. This task would also include some kind of ant/Maven support although that may be improved in later releases. And grails should get this feature too if possible. 2. Images support at some kind of basic level (url versioning and CSS rewriting would do).

Of course there are more features to implement in the tracker and any suggestion from you guys is very welcome. I am going through a patch where I don't feel very inspired to sit down and work on Jawr, but I hope to at least get number 1 moving soon. If anyone feels like getting on to work on some of the easy ones from the tracker, don't hesitate and get it on.

Cheers, Jordi.

________________________________ Date: Mon, 9 Mar 2009 12:09:48 -0600 From: To: Subject: Re: FW: Forum: JAWR support for images

I have not done anything with regards to image access using jawr. It sounds like a neat feature, and image expiry is something I'm investigating now. But I never thought to use jawr for that. I've been thinking about adding a version number to the end of my image calls: And manually incrementing the version as the image is updated. If the tag lib could help with this, I'd be all for it. -Ruby On Mon, Mar 9, 2009 at 11:44 AM, Jordi Sellés <> wrote:

Hi everyone,

Frankly, do you have any news regarding image support? Someone asked at the forums:

Date: Mon, 9 Mar 2009 10:19:48 -0700 From: To: Subject: Forum: JAWR support for images

There is a new message at:

Project: jawr Forum: Support forum

Poster: guest Date: Mon Mar 09 10:19:29 PDT 2009 Attachments: 0

Message body:

We are using JAWR to manage CSS and JS files, and it works great for those purposes.

I'm considering what the best approach is for images. We could use a servlet filter to set long expiration dates, but that will then require having some version / hash in the URL so that we can move them as needed. Further, for static css files containing image paths, that would require modifying the css to reflect the new version / hash (either by manually editing the file or dynamically modifying it).

JAWR already is setup to modify css files, so I was considering the amount of work to make this work well for jawr; e.g.:

* set jawr up to support bundle definition for images (or resources in general) * extend / modify the existing css rewriting processor to generate links to these images / resources as necessary * generate a version or unique code for the file -- it could be the last mod date for the file or an md5 hash * have jawr strip out the version / code, proxy the underlying image, and add caching headers * add a custom tag for images (which would generate a reference if appropriate that would pass through the jawr servlet's handling and would include the unique code)

Is anyone currently looking at doing something like this? Any contrary suggestions?

-- Gregg

Regards, Jordi.

________________________________ Disfruta antes que nadie del nuevo Windows Live Messenger

-- -Matt Ruby-

________________________________ Disfruta antes que nadie del nuevo Windows Live Messenger

________________________________ Diferentes formas de estar en contacto con amigos y familiares. Descúbrelas. Descúbrelas.