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

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(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/