[jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature

[Pete Muir]

Why don't we specify that only bundled resources are required to be  
supported, and that a container may portably support installed  
libraries?

Mojarra and other implementations would be able to provide this  
support via a vendor specific SPI.

On 4 Sep 2009, at 02:16, Norbert Truchsess wrote:

> 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
>>
>