[
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298923#comment-16298923
]
Paul Nicolucci commented on MYFACES-4175:
-----------------------------------------
So looking at this a bit more closely I see what's going on here. The reason
the application is not loading resources from WEB-INF/resources/templates but
is from WEB-INF/templates is because the application defines the following in
the web.xml:
{code:java}
<context-param>
<param-name>
javax.faces.WEBAPP_RESOURCES_DIRECTORY
</param-name>
<param-value>WEB-INF/resources</param-value>
</context-param>
{code}
If I remove the above then the tempaltes in WEB-INF/resources/templates can be
loaded. We won't load templates from the specified directory or default
/resources directory due to the change in RootExternalContextResourceLoader
If everyone is in agreement that this is the behavior we have to introduce for
jsf2.3 then I think we are ok.
> 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)
