Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9D660200D5D for ; Wed, 20 Dec 2017 20:01:04 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 987DF160C15; Wed, 20 Dec 2017 19:01:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id C0CB4160BF9 for ; Wed, 20 Dec 2017 20:01:03 +0100 (CET) Received: (qmail 39049 invoked by uid 500); 20 Dec 2017 19:01:02 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 39039 invoked by uid 99); 20 Dec 2017 19:01:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2017 19:01:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 24300180352 for ; Wed, 20 Dec 2017 19:01:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.718 X-Spam-Level: * X-Spam-Status: No, score=1.718 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_FAIL=0.919] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id bmB4mDXgwUvy for ; Wed, 20 Dec 2017 19:01:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id D33A15F30B for ; Wed, 20 Dec 2017 19:01:00 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 5020EE012B for ; Wed, 20 Dec 2017 19:01:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 1325B240DA for ; Wed, 20 Dec 2017 19:01:00 +0000 (UTC) Date: Wed, 20 Dec 2017 19:01:00 +0000 (UTC) From: "Paul Nicolucci (JIRA)" To: dev@myfaces.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 20 Dec 2017 19:01:04 -0000 [ https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298923#comment-16298923 ] Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 7:00 PM: ------------------------------------------------------------------- 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} javax.faces.WEBAPP_RESOURCES_DIRECTORY WEB-INF/resources {code} If I remove the above then the templates 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. was (Author: paul.nicolucci): 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} javax.faces.WEBAPP_RESOURCES_DIRECTORY WEB-INF/resources {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)