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

[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

-- 
| ed.burns at sun.com  | office: 408 884 9519 OR x31640
| homepage:         | http://ridingthecrest.com/