Hi Ed,
Sorry for the late answer. I was a bit off the grid in the last days..
It is true that the RelativeResourceHandler currently does not support
library or resource versions in the JSF 2.0 kind of way. The problem
is that, again, you have to have every information in the URL path.
Thus you also have to have the resource/library version in the URL
path, which only works if you have 1 version with no relative
cross-references. Otherwise it will be a problem.
Now the url-version, which is currently implemented in the
RelativeResourceHandler, accomplishes something else. When you deploy
a webapp (e.g. version 1.0.0) to the public, then every user will have
most of the resources (mostly CSS files) cached in their browsers
(forever). If you now do an update to a resource and re-deploy the
webapp, all the users which already have a cached version of the old
resource will not get the update in the CSS, unless they explicitly
hit F5 (or wait for the cached version to be dropped, which could be a
long time). To circumvent this problem I created a way to have a
version in the resource URL. If you update a resource, you now simply
have to change the version and all your users will get new resource
URLs and thus ignore the cached (old) resource from their browsers.
Example for style.css:
1) webapp-deploy
resource-URL:
http://www.acme.com/faces/javax.faces.resource/1.0.0/css/style.css
--> browsers cache this resource
2) change style.css and set version to 1.0.1
3) re-deploy webapp
resource-URL:
http://www.acme.com/faces/javax.faces.resource/1.0.1/css/style.css
--> browsers think it is a new resource and fetch it + ignore the old one
> * If you want relative resource loading to work, you must not have
> versioned resources or versioned libraries.
It does currently seem so, but maybe we can find an agreement here,
that allows different versions of resources/libraries, but maybe with
the drawback of a little less freedom in the relative reference
mechanism.
Suggestions are welcome!
Regards,
Jakob
Am 20. März 2012 21:56 schrieb Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Tue, 20 Mar 2012 13:47:21 -0700, Edward Burns <edward.burns_at_oracle.com> said:
>
>>>>>> On Tue, 20 Mar 2012 13:30:40 -0700, Edward Burns <edward.burns_at_oracle.com> said:
> EB> A resource path from Jakob's impl looks like
> EB> "/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0
> EB> refer to library version or resource version?
>
> EB> It appears to refer to a "url-version". Jakob, can you please explain
> EB> what that is?
>
> One more question for the day on this. It seems like your
> RelativeResourceHandler doesn't support versioned resources or versioned
> libraries, is that correct? Because we *do* support this in JSF 2.0, I
> don't think we can simply fail to support it in 2.2. It seems we have
> another simplifying assumption to add to the system. Let's review the
> current list of simplifying assumptions.
>
> * RelativeResourceHandler only works with prefix mapped applications.
>
> This is probably not an issue if we specify that javax.faces.resource
> is prefixed mapped to go straight to
> ResourceHandler.handleResourceRequest(). With this proviso, the app
> can use prefix mapping for JSF pages, but resource requests will
> always be rendered such that they go to the prefix mapped
> javax.faces.resource.
>
> * If you want relative resource loading to work, you must not have
> versioned resources or versioned libraries.
>
> Is this really true?
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at