myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Sartoris (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir
Date Thu, 07 Dec 2017 22:57:00 GMT

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

Jay Sartoris edited comment on MYFACES-4175 at 12/7/17 10:56 PM:
-----------------------------------------------------------------

I've done a fair amount of debugging and I can explain this problem more clearly now I think.
We have a test that is working in MyFaces 2.2 and also in Mojarra 2.3, but fails in MyFaces
2.3.
The test has a ui:composition tag and the template attribute calls a backing bean to map the
resource to the Facelet view.
The bean uses VDL.viewExists...which ends up returning null.

{code:java}
String viewId = "resources/templates/basicTemplate.xhtml";

ResourceHandler resourceHandler = facesContext.getApplication().getResourceHandler();

ViewDeclarationLanguage vdl = facesContext.getApplication().getViewHandler().getViewDeclarationLanguage(facesContext,
viewId);
ViewResource viewResource = null;
if (vdl.viewExists(facesContext, viewId)) {
    viewResource = resourceHandler.createViewResource(facesContext, viewId);
}

// Get the URL of the resource
if (viewResource != null) {
    return viewResource.getURL();
}
{code}

The reason viewExists returns false is because the org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
method returns null if the resourceId starts with the resources directory.  This check was
added in JSF 2.3.  
{code:java}
public URL getResourceURL(String resourceId)
{
    try
    {
       String correctedResourceId = resourceId.startsWith("/") ? resourceId : "/"+resourceId;
        if (correctedResourceId.startsWith(contractsDirectory) || 
           correctedResourceId.startsWith(resourcesDirectory))
        {
           return null;
        }
 ....
{code}
Another section of the code path supports this addition: 
The comment in the org.apache.myfaces.application.ResourceHandlerImpl.createViewResource method
states, in part, that:
{code:java}
// - A view resource cannot be created from /resources or META-INF/resources.
{code}
However, this same comment is in the JSF 2.2 version of the file as well.  The only difference
in the code path are the checks added to the getResourceURL method in 2.3.  
Also, I have been unable to find anywhere in the JSF spec which states that the view resources
cannot be located in the resources directory. 
Could I please get some clarification on this change?  Since this is working in Mojarra 2.3
and also in MyFaces 2.2, then it will be viewed as a regression in MyFaces 2.3 and we'll need
to be able to provide supporting documentation to explain the change.
Thanks



was (Author: sartoris):
I've done a fair amount of debugging and I can explain this problem more clearly now I think.
We have a test that is working in MyFaces 2.2 and also in Mojarra 2.3, but fails in MyFaces
2.3.
The test has a ui:composition tag and the template attribute calls a backing bean to map the
resource to the Facelet view.
The bean uses VDL.viewExists...which ends up returning null.

{code:java}
String viewId = "resources/templates/basicTemplate.xhtml";

ResourceHandler resourceHandler = facesContext.getApplication().getResourceHandler();

ViewDeclarationLanguage vdl = facesContext.getApplication().getViewHandler().getViewDeclarationLanguage(facesContext,
viewId);
ViewResource viewResource = null;
if (vdl.viewExists(facesContext, viewId)) {
    viewResource = resourceHandler.createViewResource(facesContext, viewId);
}

// Get the URL of the resource
if (viewResource != null) {
    return viewResource.getURL();
}
{code}

The reason viewExists returns false is because the org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
method returns null if the resourceId starts with the resources directory.  This check was
added in JSF 2.3.  

Another section of the code path supports this addition: 
The comment in the org.apache.myfaces.application.ResourceHandlerImpl.createViewResource method
states, in part, that:
{code:java}
// - A view resource cannot be created from /resources or META-INF/resources.
{code}
However, this same comment is in the JSF 2.2 version of the file as well.  The only difference
in the code path are the checks added to the getResourceURL method in 2.3.  
Also, I have been unable to find anywhere in the JSF spec which states that the view resources
cannot be located in the resources directory. 
Could I please get some clarification on this change?  Since this is working in Mojarra 2.3
and also in MyFaces 2.2, then it will be viewed as a regression in MyFaces 2.3 and we'll need
to be able to provide supporting documentation to explain the change.
Thanks


> 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
>         Attachments: JSFTestResources.war
>
>
> 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)

Mime
View raw message