Options to resolve the issue -------------------------------------- 1. Update the specification to state that versioned resources are only supported when they are included as resources under /resources 2. Update the specification to state that only classpath resources included in the web application will be searched. This means that resources installed to the server classpath will not be considered. Implementations could then explode the resources found within the JAR files included in the application to a temporary directory. The classpath searching algorithm would then search this temporary directory instead. Doing this for server classpath resources may be impossible depending on the container.

ACTION: Please choose one of the two options above or suggest another. Silence implies consent with option 2. Please reply in a timely fashion.

I guess most major containers are affected by this - e.g. weblogic uses zip:-protocol for all kind of jar-files. +1 for Option 2 -Norbert Am Donnerstag, den 27.08.2009, 11:26 -0700 schrieb Ed Burns: > Thanks to Ryan Lubke for bringing this up and authoring the first > draft > of this email. > > Recall the resource versioning scheme we have that enables runtime > upgrades of component resources without redeployment. A valid > resource > identifier has the following parts. Optional parts are in square > brackets. > > [libraryName/][libraryVersion/]resourceName[/resourceVersion] > > Recall also that the default ResourceHandler supports loading > resources > in an "exploded" fashion, from the <web app root>/resources > directory, > and also from the classpath via entries in the META-INF/resources > directory. > > Summary of Issue > ----------------------------------- > > Derivation of library and or resource versions is currently > dependent on > the URL type exposed when searching for classpath resources. Within > Mojarra, we can properly find versions if the URL protocol is > 'file' or > 'jar'. > > URLs with a file protocol can be used to construct a File instance > with > which we can use standard Java File IO to find the versions. > > URLs with a jar protocol allow access to the JAR file itself with > which > we can use the standard JAR apis to navigation through the JAR and > find > versions. > > If the URL protocol is of any other type, we really have no way to > derive the version information in a portable manner. > > It just so happens that there are several cases when it's not > possible > to meet the version scanning requirements in all containers and in > all > deployment scenarios. For example, in glassfish, if you deploy your > resource in an OSGi bundle, we don't see jar: or file: URLs. In > another > example, JBoss AS has its own loading scheme thit also is not jar: or > file:. Therefore, we cannot guarantee the version scanning feature > will > work in all cases. > > > Options to resolve the issue > -------------------------------------- > > 1. Update the specification to state that versioned resources are > only > supported when they are included as resources under /resources > > 2. Update the specification to state that only classpath resources > included in the web application will be searched. This means that > resources installed to the server classpath will not be > considered. > > Implementations could then explode the resources found within the > JAR files included in the application to a temporary directory. > The > classpath searching algorithm would then search this temporary > directory instead. Doing this for server classpath resources > may be > impossible depending on the container. > > ACTION: Please choose one of the two options above or suggest > another. > Silence implies consent with option 2. Please reply in a timely > fashion. > > Sincerely, > > Ed >

On Sun, Sep 6, 2009 at 9:46 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: Why don't we specify that only bundled resources are required to be supported, and that a container may portably support installed libraries? That's precisely what I had in mind. Mojarra and other implementations would be able to provide this support via a vendor specific SPI. Should the SPI be part of the spec or something the implementation provides? Perhaps Mojarra can introduce an SPI that we later promote in an MR?