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

[Norbert Truchsess]

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
>