Without another option, +1 for option 2.<br clear="all">---<br>Kito D. Mann -- Author, JavaServer Faces in Action<br><a href="http://twitter.com/kito99">http://twitter.com/kito99</a> <a href="http://twitter.com/jsfcentral">http://twitter.com/jsfcentral</a><br>
JSF 2 Seminar Oct 6tth: <a href="http://www.regonline.com/jsf2seminar">http://www.regonline.com/jsf2seminar</a><br>JSF Summit Conference Dec 1st-4th in Orlando: <a href="http://www.jsfsummit.com">http://www.jsfsummit.com</a><br>
<a href="http://www.JSFCentral.com">http://www.JSFCentral.com</a> - JavaServer Faces FAQ, news, and info<br>+1 203-404-4848 x3<br>
<br><br><div class="gmail_quote">On Thu, Aug 27, 2009 at 2:26 PM, Ed Burns <span dir="ltr"><<a href="mailto:Ed.Burns@sun.com">Ed.Burns@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks to Ryan Lubke for bringing this up and authoring the first draft<br>
of this email.<br>
<br>
Recall the resource versioning scheme we have that enables runtime<br>
upgrades of component resources without redeployment. A valid resource<br>
identifier has the following parts. Optional parts are in square<br>
brackets.<br>
<br>
[libraryName/][libraryVersion/]resourceName[/resourceVersion]<br>
<br>
Recall also that the default ResourceHandler supports loading resources<br>
in an "exploded" fashion, from the <web app root>/resources directory,<br>
and also from the classpath via entries in the META-INF/resources<br>
directory.<br>
<br>
Summary of Issue<br>
-----------------------------------<br>
<br>
Derivation of library and or resource versions is currently dependent on<br>
the URL type exposed when searching for classpath resources. Within<br>
Mojarra, we can properly find versions if the URL protocol is 'file' or<br>
'jar'.<br>
<br>
URLs with a file protocol can be used to construct a File instance with<br>
which we can use standard Java File IO to find the versions.<br>
<br>
URLs with a jar protocol allow access to the JAR file itself with which<br>
we can use the standard JAR apis to navigation through the JAR and find<br>
versions.<br>
<br>
If the URL protocol is of any other type, we really have no way to<br>
derive the version information in a portable manner.<br>
<br>
It just so happens that there are several cases when it's not possible<br>
to meet the version scanning requirements in all containers and in all<br>
deployment scenarios. For example, in glassfish, if you deploy your<br>
resource in an OSGi bundle, we don't see jar: or file: URLs. In another<br>
example, JBoss AS has its own loading scheme thit also is not jar: or<br>
file:. Therefore, we cannot guarantee the version scanning feature will<br>
work in all cases.<br>
<br>
<br>
Options to resolve the issue<br>
--------------------------------------<br>
<br>
1. Update the specification to state that versioned resources are only<br>
supported when they are included as resources under /resources<br>
<br>
2. Update the specification to state that only classpath resources<br>
included in the web application will be searched. This means that<br>
resources installed to the server classpath will not be considered.<br>
<br>
Implementations could then explode the resources found within the<br>
JAR files included in the application to a temporary directory. The<br>
classpath searching algorithm would then search this temporary<br>
directory instead. Doing this for server classpath resources may be<br>
impossible depending on the container.<br>
<br>
ACTION: Please choose one of the two options above or suggest another.<br>
Silence implies consent with option 2. Please reply in a timely<br>
fashion.<br>
<br>
Sincerely,<br>
<br>
Ed<br>
<font color="#888888"><br>
--<br>
| <a href="mailto:ed.burns@sun.com">ed.burns@sun.com</a> | office: 408 884 9519 OR x31640<br>
| homepage: | <a href="http://ridingthecrest.com/" target="_blank">http://ridingthecrest.com/</a><br>
</font></blockquote></div><br>