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 927C1200D68 for ; Thu, 28 Dec 2017 17:50:49 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 90B18160C16; Thu, 28 Dec 2017 16:50:49 +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 87FDB160C0C for ; Thu, 28 Dec 2017 17:50:48 +0100 (CET) Received: (qmail 42224 invoked by uid 500); 28 Dec 2017 16:50:47 -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 42214 invoked by uid 99); 28 Dec 2017 16:50:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Dec 2017 16:50:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id C8E43C4796 for ; Thu, 28 Dec 2017 16:50:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, TVD_FW_GRAPHIC_NAME_MID=0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id JrHM8T4bs5vp for ; Thu, 28 Dec 2017 16:50:45 +0000 (UTC) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2F9AF5F396 for ; Thu, 28 Dec 2017 16:50:45 +0000 (UTC) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBSGjCkc079185 for ; Thu, 28 Dec 2017 11:50:44 -0500 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.75]) by mx0a-001b2d01.pphosted.com with ESMTP id 2f50t6ugus-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 28 Dec 2017 11:50:43 -0500 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Thu, 28 Dec 2017 16:50:42 -0000 Received: from us1a3-smtp01.a3.dal06.isc4sb.com (10.106.154.95) by smtp.notes.na.collabserv.com (10.106.227.123) with smtp.notes.na.collabserv.com ESMTP; Thu, 28 Dec 2017 16:50:33 -0000 Received: from us1a3-mail107.a3.dal06.isc4sb.com ([10.146.45.243]) by us1a3-smtp01.a3.dal06.isc4sb.com with ESMTP id 2017122816514282-626484 ; Thu, 28 Dec 2017 16:51:42 +0000 MIME-Version: 1.0 In-Reply-To: Subject: Re: Dev Discussion - JSF 2.3 ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY different between MyFaces and Mojarra To: "MyFaces Development" From: "Paul Nicolucci" Date: Thu, 28 Dec 2017 11:50:11 -0500 References: X-KeepSent: 73AECBFB:60DFD227-00258204:005C69EF; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP5 SHF106 December 12, 2015 X-LLNOutbound: False X-Disclaimed: 29679 X-TNEFEvaluated: 1 Content-type: multipart/related; Boundary="0__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F" x-cbid: 17122816-3815-0000-0000-00000466D2DE X-IBM-SpamModules-Scores: BY=0.290024; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.369042; ST=0; TS=0; UL=0; ISC=; MB=0.008587 X-IBM-SpamModules-Versions: BY=3.00008275; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000244; SDB=6.00966855; UDB=6.00489400; IPR=6.00746828; BA=6.00005761; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018755; XFM=3.00000015; UTC=2017-12-28 16:50:41 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2017-12-28 13:06:28 - 6.00007825 x-cbparentid: 17122816-3816-0000-0000-0000AE3DF146 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-28_11:,, signatures=0 X-Proofpoint-Spam-Reason: safe archived-at: Thu, 28 Dec 2017 16:50:49 -0000 --0__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F Content-type: multipart/alternative; Boundary="1__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F" --1__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F Content-Transfer-Encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Any updates here? We should work to make a decision on this soon so we can get 2.3.0 completed. Any thoughts on what changes are required? Thanks, Paul Nicolucci From: Thomas Andraschko To: MyFaces Development Date: 12/09/2017 03:08 PM Subject: Re: Dev Discussion - JSF 2.3 ResourceVisitOption.TOP=5FLEVEL=5FVIEWS=5FONLY different between MyFaces and Mojarra I asked why this feature is actually needed and become further feedback: The idea is that OmniFaces will eventually throw out it's now proprietary FacesViews feature in favour of the standardised APIs, and perhaps will only add some extra things. Perhaps it's possible to add a clarification to the spec for JSF 2.4 about the intention of the various view hints, with some examples etc. 2017-12-08 20:28 GMT+01:00 Thomas Andraschko : I talked with Arjan about that topic. Here is the statement: I: How was it desinged? I actually agree with Leo and the MyFaces impl that views are actually only files=A0that can be served by the browser and th= ey must be placed inside the webapp directory. Templates, includes and else can be placed in jars but is not a "view" actually. WDYT? Arjan: The above is not entirely correct. The design (contract) is that it returns whatever the installed VDL(s) recognise as a view. The feature should delegate to the VDL and negotiate with that. For instance, the default Facelet VDL is able to load views from a jar since JSF 2.2. Another custom VDL might load views from a database, from an external folder, or what have you. So the idea is not to make any assumptions about where views van reside or not, but ask the VDL, and return whatever the VDL supports. WDYT Leo? 2017-11-24 2:00 GMT+01:00 Leonardo Uribe : Hi I think MyFaces behavior is correct here. The reason is you will never add views inside META-INF or WEB-INF folders, but you could add templates there. But a template is not a view. That is what I understand with "top level views". regards, Leonardo Uribe 2017-11-23 19:41 GMT-05:00 Thomas Andraschko < andraschko.thomas@gmail.com>: I think we should align myfaces here. A issue + patch would be great. Am Samstag, 18. November 2017 schrieb Paul Nicolucci : The javadoc for ResourceVisitOption.html says the following: https://javaee.github.io/javaee-spec/javadocs/javax/faces/application= /ResourceVisitOption.html public static final=A0ResourceVisitOption=A0TOP=5FLEVEL=5FVIEWS=5FONLY Only visit resources that are top level views, i.e. views that can be used to serve a request as opposed to those that can only be used for includes. Thanks, Paul Nicolucci Inactive hide details for Thomas Andraschko ---11/18/2017 07:22:32 AM---Did you checked the spec texts? 2017-11-17 19:56 GMT+01Thomas Andraschko ---11/18/2017 07:22:32 AM---Did you checked the spec texts? 2017-11-17 19:56 GMT+01:00 Paul Nicolucci : From: Thomas Andraschko To: MyFaces Development Date: 11/18/2017 07:22 AM Subject: Re: Dev Discussion - JSF 2.3 ResourceVisitOption.TOP=5FLEVEL=5FVIEWS=5FONLY different between MyFa= ces and Mojarra Did you checked the spec texts? 2017-11-17 19:56 GMT+01:00 Paul Nicolucci : Hello, I was testing out the ResourceHandler.getViewResources() today and I noticed that we have quite a behavior different between the two implementations. Take the following application for example: testApplication - /depth2/index.xhtml -META-INF/index.xhtml -WEB-INF/index.xhtml - index.xhtml - test Mojarra getViewResources( call with ResourceVisitOptions ) /index.xhtml /depth2/index.xhtml Mojarra getViewResources ( call without ResourceVisitOptions ) /index.xhtml /depth2/index.xhtml META-INF/index.xhtml WEB-INF/index.xhtml MyFaces getViewResources( call with ResourceVisitOptions ) /index.xhtml /depth2/index.xhtml MyFaces getViewResources( call without ResourceVisitOptions ) /index.xhtml /test /depth2/index.xhtml In MyFaces if we use the ResourceVisitOptions then we filter out any views that don't contain a valid suffix ( in the above case /test ). In addition MyFaces never returns any views in WEB-INF and META-INF In Mojarra if we use the ResourceVisitOptions then anything in WEB-INF and META-INF is not included. In addition Mojarra never returns any views without a valid suffix. I think we need a dev discussion to determine if we want to stick with our current behavior or change it. Thanks, Paul Nicolucci --1__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F Content-Transfer-Encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Any updates here? We should work to make a = decision on this soon so we can get 2.3.0 completed.

Any thoughts on what changes are required?

Thanks,

Paul Nicolucci

3D"InactiveThomas Andraschk= o ---12/09/2017 03:08:38 PM---I asked why this feature is actually needed a= nd become further feedback: The idea is that OmniFaces

From: Thomas An= draschko <andraschko.thomas@gmail.com>
To: MyFaces Development <d= ev@myfaces.apache.org>
Date= : 12/09/2017 03:08 PM
Subject: Re: Dev Di= scussion - JSF 2.3 ResourceVisitOption.TOP=5FLEVEL=5FVIEWS=5FONLY different= between MyFaces and Mojarra




I asked why this fe= ature is actually needed and become further feedback:

The idea is th= at OmniFaces will eventually throw out it's now proprietary FacesViews feat= ure in favour of the standardised APIs, and perhaps will only add some extr= a things.
Perhaps it's possible to add a clarification to the spec for J= SF 2.4 about the intention of the various view hints, with some examples et= c.

2017-12-08 20:28 GMT+01:00 Thomas Andraschko <andraschko.thomas@gmail.com>:
    I talked with Arjan about that topic.
    Here is the statement:

    = I:
    How was it desinged? I actually agree with Leo and t= he MyFaces impl that views are actually only files=A0that can be served by = the browser and they must be placed inside the webapp directory. Templates,= includes and else can be placed in jars but is not a "view" actu= ally.
    WDYT?

    Arjan:
    The above is= not entirely correct. The design (contract) is that it returns whatever th= e installed VDL(s) recognise as a view. The feature should delegate to the = VDL and negotiate with that. For instance, the default Facelet VDL is able = to load views from a jar since JSF 2.2.

    Another custom VDL might loa= d views from a database, from an external folder, or what have you.

    = So the idea is not to make any assumptions about where views van reside or = not, but ask the VDL, and return whatever the VDL supports.


    WDYT= Leo?

    2017-11-24 2:00 GMT+01:00 Leonardo Uribe <lu4242@gm= ail.com>:
    Hi

    I think MyFaces behavior is correc= t here. The reason is you will never add views inside META-INF or WEB-INF f= olders, but you could add templates there. But a template is not a view. Th= at is what I understand with "top level views".

    regards,
    Leonardo Uribe

    2017-11-23 19:41 GMT-05:00 Thomas Andraschko &l= t;andraschko.thomas@gmail.com>:
      I think we should align myfaces here. A issue + patch would be great.

      Am Samstag, 18. November 2017 schrieb Paul Nicolucci :
      The javadoc for ResourceVisitOption.html says the following: https://javaee.github.io/ja= vaee-spec/javadocs/javax/faces/application/ResourceVisitOption.html<= /u>

      public static final=A0      ResourceVisitOption=A0TOP=5FLEVEL=5FVIEWS= =5FONLY
      Only visit resources that are top level views, i.e. views t= hat can be used to serve a request as opposed to those that can only be use= d for includes.

      Thanks,
      =
      Paul Nicolucci


      3D"InactiveThomas Andraschko ---11/18/2017 07:22:32 AM---Did you checked the spec t= exts? 2017-11-17 19:56 GMT+01:00 Paul Nicolucci <pnicoluc@us.ibm.com>= :

      From:       Thomas Andraschko <andraschko.thomas@gmail.com>
      To:       MyFaces Developm= ent <dev@myfaces.apache.org>
      Date:       11/18/2017 07:22 AM
      Subject:       Re: Dev Discussio= n - JSF 2.3 ResourceVisitOption.TOP=5FLEVEL=5FVIEWS=5FONLY different betwee= n MyFaces and Mojarra



      Did you checked the spec texts?

      2017-11-17 19:= 56 GMT+01:00 Paul Nicolucci <pnicoluc@us.ibm.= com>:=20
          Hello,

          I was testing out the ResourceHandl= er.getViewResources() today and I noticed that we have quite a behavior dif= ferent between the two implementations.

          Take the following applicati= on for example:

          testApplication
          - /depth2/index.xhtml
          -META-IN= F/index.xhtml
          -WEB-INF/index.xhtml
          - index.xhtml
          - test

          Moj= arra getViewResources( call with ResourceVisitOptions )
          /index.xhtml /de= pth2/index.xhtml

          Mojarra getViewResources ( call without ResourceVis= itOptions )
          /index.xhtml /depth2/index.xhtml META-INF/index.xhtml WEB-IN= F/index.xhtml

          MyFaces getViewResources( call with ResourceVisitOptio= ns )
          /index.xhtml /depth2/index.xhtml

          MyFaces getViewResources( c= all without ResourceVisitOptions )
          /index.xhtml /test /depth2/index.xhtm= l

          In MyFaces if we use the ResourceVisitOptions then we filter out a= ny views that don't contain a valid suffix ( in the above case /test ). In = addition MyFaces never returns any views in WEB-INF and META-INF

          In = Mojarra if we use the ResourceVisitOptions then anything in WEB-INF and MET= A-INF is not included. In addition Mojarra never returns any views without = a valid suffix.

          I think we need a dev discussion to determine if we = want to stick with our current behavior or change it.

          Thanks,
          Paul Nicolucci






--1__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F-- --0__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FB@> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=8FBB0897DFCFEF7F8f9e8a93df938690918c8FBB0897DFCFEF7F--