Hi<br><br>On this issue:<br><br><a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567</a><br><br>I attached a minimal patch to solve ResourceResolver problem. The idea is just<br>
method called:<br><br>public boolean existsViewId(FacesContext context, String viewId)<br><br><span id="result_box" class="short_text" lang="en"><span style="" title="">and add the method ViewHandler.getViewDeclarationLanguageFromRawViewId(FacesContext, String)<br>
to resolve the ambiguity</span></span> on ViewHandler.getViewDeclarationLanguage.<br><br>regards,<br><br>Leonardo<br><br><div class="gmail_quote">2010/10/12 Leonardo Uribe <span dir="ltr"><<a href="mailto:lu4242@gmail.com">lu4242@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi<br><br>These are the answers to the questions asked (answer inside the mail <br>sent could make things more confusing):<br>
<br>FIRST PROBLEM: Fix Resource Resolver<br> <br> AS >> In what way (the ResourceResolver) does not work?<br>
AS >> It this is broken, it definitely needs to be fixed. <br> AS >> We need more details on exactly what behavior is broken.<br> <br> The problem happen only when suffix mapping is used. In few words,<br>
When this mapping is used, it is required to check if a <br> physical resource exists, usually calling ExternalContext.getResource. <br> Since the algorithm described on the spec does not take into<br> account ResourceResolver, a http 404 not found response is sent back.<br>
(The reference that needs to be fixed on the spec is JSF 2.0 <br> section 7.5.2 Default ViewHandler Implementation, when it describe <br> the requeriments of ViewHandler.deriveViewId.)<br> <br> AS >> What is the issue # for this problem?<br>
AS >> Is this a Mojarra issue? MyFaces? Spec? All of the above?<br> <br> The issue in MyFaces is this one:<br> <br> <a href="https://issues.apache.org/jira/browse/MYFACES-2628" target="_blank">https://issues.apache.org/jira/browse/MYFACES-2628</a><br>
<br> It was first mentioned on this mailing list under the topic:<br> <br> [jsr-314-open] javax.faces.view.facelets.ResourceResolver cannot be fully overriden<br> <br> Then it was added some comments on this spec issue:<br>
<br> <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=781" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=781</a><br> <br> It was also found this issue on Mojarra<br>
<br> <a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567" target="_blank">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1567</a> <br> <br> Maybe we should create an independent issue for this one on the spec issue tracker<br>
<br> AS >> We are using it (ResourceResolver) here. Now I am getting worried that <br> AS >> maybe our code is broken. :-) Though Jason also blogged on this topic here:<br> AS >> <a href="http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/" target="_blank">http://blogs.steeplesoft.com/2010/05/putting-facelets-in-a-jar/</a><br>
AS >> Which makes me think that this must be minimally working.<br> <br> I think you are using ResourceResolver with applications that uses prefix <br> mapping. The hack on the blog works but by accident. Try the same example,<br>
but without configure ResourceResolver and it will work, because we are<br> overriding ExternalContext.getResource, which it is used to check if a resource<br> exists or not.<br> <br> The proposal at first view, to solve this one is add a method on <br>
ViewDeclarationLanguageFactory called existsViewId(), so the algorithm on <br> ViewHandler.deriveViewId just delegate to this one and that one delegate to <br> different ViewDeclarationLanguage implementations. But it seems better to move all<br>
logic from section 7.5.2 ViewHandler.deriveViewId. Here I have to mention something<br> I said on this discussion:<div class="im"><br> <br> [jsr-314-open] Should the ViewDeclarationLanguage be responsible to indicate if a <br>
viewId can be created?<br> <br></div> On mojarra, this is the code on MultiViewHandler.getViewDeclarationLanguage:<br> <br> public ViewDeclarationLanguage getViewDeclarationLanguage(FacesContext context,<br>
String viewId) {<br> <br> String actualViewId = derivePhysicalViewId(context, viewId, false);<br> return vdlFactory.getViewDeclarationLanguage(actualViewId);<br>
<br> }<br> <br> Now on myfaces is this:<br> <br> @Override<br> public ViewDeclarationLanguage getViewDeclarationLanguage(<br> FacesContext context, String viewId)<br> {<br>
// return a suitable ViewDeclarationLanguage implementation for the given viewId<br> return _vdlFactory.getViewDeclarationLanguage(viewId);<br> }<br> <br> The difference is subtle, but very, very important. This method is called from many <br>
locations, but only once (from RestoreViewPhase) it is passed the "raw" viewId. <br> To "derive" the physical viewId it is required to know if prefix or suffix mapping is <br> used and if suffix mapping is used, try to check if a view "resource" exists or not <br>
with different derived ids with the extensions configured ".xhtml .jsp".<br> <br> In this case, MyFaces "derive" the physical viewId before call getViewDeclarationLanguage<br> from RestoreViewPhase. In theory, we should call from RestoreViewPhase algorithm a method<br>
exposed by ViewHandler. I'm not have clear the details yet.<br> <br>SECOND PROBLEM: Fix suffix definition for vdls<br><br> AS >> This seems like a good thing to do. Are you thinking that we'll add a new <br>
AS >> hook on ViewDeclarationLanguage that allows the VDL implementation to decide<br> AS >> whether or not it can handle a particular view id? <br><br> In theory, both myfaces and mojarra has already that, but it is left as an implementation<br>
detail. Take a look at ViewDeclarationLanguageFactory implementation and you'll see<br> some code to decide which VDL should handle the viewId identified (note handle a viewId<br> is different to check if the viewId exists, which it is required for the first one).<br>
<br> AS >> Do we have a spec issue logged for this topic?<br><br> Not yet. The intention is create one based on all previous discussion. <br><br>THIRD PROBLEM: Fix specific suffix handling for facelets vdl<div class="im">
<br>
<br> BS>>>>>> In the JAR case, it doesn't care about the VDL at all, it is simply<br> BS>>>>>> loading the requested resources out of the JAR regardless of extension.<br> <br>
</div>
LU>>>>So, what's the point about have this configuration on a JAR, if there will be no<br> LU>>>>resources using such extensions inside it?. If all resources used by facelets are<br> LU>>>>inside the WAR or in the webapp directory, shouldn't that param be configured on<br>
LU>>>>web.xml or only in faces config application resource (WEB-INF/faces-config.xml).<br> <br> LU>>>>It's more, if I have the xml configuration proposed on JAR META-INF/faces-config.xml,<br>
LU>>>>what someone could expect is the configuration applies to case 1 (composite<br> LU>>>>component resource files), and not globally, which it is the intention.<br><br> AS>>I don't completely follow this. Could you explain?<br>
<br> The proposal "as is" has a problem. It we have the configuration on a JAR, the way the <br> mappings are written does not suggest which resources applies to it, or in other words,<br> it is not clear if the resources found outside the JAR are also affected or not.<br>
<br> As I said before, a JAR file could contain resources that could be used by facelets <br> in two situations:<br> <br> 1. On META-INF/resources/[localePrefix/][libraryName/]resourceName as a composite <br>
component resource file.<div class="im"><br> 2. On any directory but it should be created a class that implements <br> javax.faces.view.facelets.ResourceResolver, so it can get the resource properly.<br> <br>
</div> If I put that configuration on a JAR, my first thought is this configuration only applies to <br>
the resources inside the JAR. Since ResourceResolver is affected by "global mappings", this rule<br> should only applies to composite component definitions and related facelets, right?.<br> <br> But the intention is affect the "global mapping", since the resources will be loaded through<br>
ResourceResolver (I don't know your particular use case, so I'm supposing here). It this<br> is true, it has sense to put it on a JAR, but that condition must be made explicit, using<br> a more "suggestive" name and it should be possible to define a custom ResourceResolver <br>
from faces-config file, otherwise it will not be possible to wrap more than 2 instances<br> (the default and the one from the web config param).<br><br> LU >>>> All three issues are related. All of them should be solved. Delaying these issues<br>
LU >>>> with partial hacks only makes things worst and even harder to understand.<br> <br> AS >> I agree that all three issues should be solved. FWIW, I think that #3 can be <br> AS >> solved independently of #1 and #2. I don't quite see why these issues should <br>
AS >> be tightly coupled. I also don't think that the proposal to fix #3 is a hack,<br> AS >> but if others think that it is, we of course need to resolve these concerns.<br> <br> From my point of view, this one is a particular case of the second one. Why? because if you<br>
add this on faces-config.xml:<div class="im"><br> <br> <faces-config-extension><br> <facelets-processing><br> <file-extension>.jspx</file-extension><br> <process-as>jspx</process-as><br>
</facelets-processing><br> <facelets-processing><br> <file-extension>.view.xml</file-extension><br> <process-as>xml</process-as><br> </facelets-processing><br>
</faces-config-extension><br> <br></div> You are not only saying "... process this suffix in mode ....", you also are implicitly <br> mapping the suffix to facelets VDL. The mode is just a configuration property that<br>
the VDL must take into account to process a viewId with this suffix. Why don't do <br> something like this (maybe you can find better names for the xml): <br> <br> <faces-config-extension><br> <vdl-configuration><br>
<vdl-id>facelets</vdl-id><br> <vdl-class>xxx.yyy.zzz.MyCustomFaceletsVDLWrapper</vdl-class><br> <vdl-global-resource-mapping><div class="im"><br> <file-extension>.jspx</file-extension><br>
</div>
<vdl-resource-mapping-config> <!-- Saved on key/value map or something like that --><div class="im"><br> <process-as>jspx</process-as><br></div> </vdl-resource-mapping-config><br>
</vdl-global-resource-mapping><br> <vdl-global-resource-mapping><div class="im"><br> <file-extension>.view.xml</file-extension><br></div> <vdl-resource-mapping-config> <!-- Saved on key/value map or something like that --><div class="im">
<br>
<process-as>xml</process-as><br></div> </vdl-resource-mapping-config><br> </vdl-global-resource-mapping><br> </vdl-configuration><br> </faces-config-extension><br>
<br> It is almost the same as we have before but with the following differences:<br> <br> 1. Every VDL has an id (like with RenderKit)<br> 2. There is an option to provide custom properties, that allow pass the "mode".<br>
3. <vdl-global-resource-mapping> tag says "... all resources that match this mapping<br> in the webapp will be processed by this VDL using these configuration params ..."<br> 4. (Optional) Allow to provide a wrapper for a VDL implementation, allowing to extend<br>
it (maybe useful for gracelets????).<br> <br>Did you see the relationship between all three problems? <br><br>- All of them require changes on ViewDeclarationLanguage/ViewDeclarationLanguageFactory. <br>- Problem (1) is enough simple to solve, because it just require some code relocation that already exists,<br>
but it is necessary to update the spec. <br>- Problem (2) is the general case of (3), so we just need to change the current patch a little bit.<br>- To make (3) and use it as expected we need (1) fixed. <br><br>I'm willing to contribute with this issue doing some code if necessary (I'll try it to see how <br>
far I can go).<div><div></div><div class="h5"><br><br>Suggestions are welcome.<br><br>best regards,<br><br>Leonardo Uribe<br>
</div></div></blockquote></div><br>