[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297284#comment-16297284
 ] 

Leonardo Uribe commented on MYFACES-4175:
-----------------------------------------

In my opinion the example submitted is invalid. The reason is you can't include 
a view inside another view and hope everything magically works. 

What I mean is a top level view is "special" and everything inside it is a 
"template". 

You can create compositions using templates, but a template cannot be a top 
level view under any circustance, and the API should provide ways to avoid that 
scenario. So, what's invalid is the call from 
resourceHandler.createViewResource(...). It doesn't make sense, that's not the 
way how that API works.

There is a test package in myfaces core impl project called 
org.apache.myfaces.view.facelets.pss.acid that has a lot of examples about how 
you can load a template dynamically to a view. There are two accepted methods: 
use component binding and dynamic subscribe to PreRenderViewEvent. 

> template XHTML file fails to load when in /resources dir
> --------------------------------------------------------
>
>                 Key: MYFACES-4175
>                 URL: https://issues.apache.org/jira/browse/MYFACES-4175
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.3.0-beta
>            Reporter: Jay Sartoris
>            Priority: Minor
>             Fix For: 2.3.0
>
>         Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>       
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>       sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>       
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>       java.lang.reflect.Method.invoke(Method.java:508)
>       javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>       javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>       org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>       org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>       
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to