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

[Kito Mann]

Without another option, +1 for option 2.
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99  http://twitter.com/jsfcentral
JSF 2 Seminar Oct 6tth: http://www.regonline.com/jsf2seminar
JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3


On Thu, Aug 27, 2009 at 2:26 PM, Ed Burns <Ed.Burns at sun.com> wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090828/f5529d49/attachment.html