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 AE9E62004F5 for ; Fri, 1 Sep 2017 19:44:43 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 5E13116C62B; Fri, 1 Sep 2017 17:44:39 +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 7B61C16C5F3 for ; Fri, 1 Sep 2017 19:44:38 +0200 (CEST) Received: (qmail 6628 invoked by uid 500); 1 Sep 2017 17:44:37 -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 6617 invoked by uid 99); 1 Sep 2017 17:44:36 -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; Fri, 01 Sep 2017 17:44:36 +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 61317183937 for ; Fri, 1 Sep 2017 17:44:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.63 X-Spam-Level: *** X-Spam-Status: No, score=3.63 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, TVD_FW_GRAPHIC_NAME_MID=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id bC2Uajlp2__p for ; Fri, 1 Sep 2017 17:44:33 +0000 (UTC) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.161.173]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 1AF555FBEA for ; Fri, 1 Sep 2017 17:44:33 +0000 (UTC) Received: by mail-yw0-f173.google.com with SMTP id s62so4340484ywg.0 for ; Fri, 01 Sep 2017 10:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aBUdTRK6oj2eHzTvmAGdEbG3og/JX+2ZqJiBHnHtWUU=; b=WAddRVlhSE45281tZJ96HId5WdMNmNSUepi8Rka7XZlFYynfLozSFkvr0pIhjmYako oBfbKDHCIyj2a6zD9kciAKHeuEJxCjJS/BwbvEjpAI+OXqHU/jbpZGP1cKikrkvBj7dg Lu548Tlig0mIrWr08GxpL0PYF1cLDvJiXuzp5jhSNjUfl+9CgRLzLw0ghL3Ug0ukemGt axJiaE8VO0JzMDXGNdWLHJiYanGmleqMBZn/CA3IdHZhlTgdNjCMmapw44fxY55QY/e+ IERfem735xvRYZ0ZjKG+E+HPmMr4Ge3gwJun6P4bdmvRmSncO7JY8MpCnw9tRBHZ7f65 wENQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aBUdTRK6oj2eHzTvmAGdEbG3og/JX+2ZqJiBHnHtWUU=; b=T+7QsDVVWnnSjYmdBK9Jc2VuDFtE9XgWlzieDpIzsH0sTiO50vqsmGlJ44aOLWVJTQ 5j6noXa+M60wkCcsZqgn+faVkLX9zi0rRqq6XPQZ/mzrbH0r1fDQsfdvg/ytjaJXwudF lgfx0MGq0Sz4YRSNrjZz5fa+3ycs0ykMcj5VSimt1KRSgdAK8sz6wiPtqsDvgjeF/csK GBLArWtfPIITIko04+VCgKp5ClJFrk7VDepuyp6VnnMBt33HayOgaIwXjMRmI+TCl3Gt e43gXBEnJOUmaWdjlSeyTyTGUObgBhwbzYrdEkpmqwNth6q+HUDh8extSMU/e4ZKr4y4 jS9g== X-Gm-Message-State: AHPjjUgCTdtJBNLBFMWViPMKQlCWEAoAvEBpHJ/SwsaPSXsKwzo3qtas U0tDNY+Tl1kD44Qlg3+QUP/ZJTtVQg== X-Google-Smtp-Source: ADKCNb7R0Z+N36kKpQSew0tm/6ZcerndpyXvmr0cvu432pOVRzrG2PN3ehNyMaYO9HJMg+B4dSuSY7Eaz2QWX+HpBDo= X-Received: by 10.129.102.6 with SMTP id a6mr2537495ywc.81.1504287871737; Fri, 01 Sep 2017 10:44:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.50.131 with HTTP; Fri, 1 Sep 2017 10:44:30 -0700 (PDT) In-Reply-To: References: From: Leonardo Uribe Date: Fri, 1 Sep 2017 12:44:30 -0500 Message-ID: Subject: Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer To: MyFaces Development Content-Type: multipart/related; boundary="001a114901a43c3a340558245071" archived-at: Fri, 01 Sep 2017 17:44:43 -0000 --001a114901a43c3a340558245071 Content-Type: multipart/alternative; boundary="001a114901a43c3a320558245070" --001a114901a43c3a320558245070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Use producers won't work. The reason? it is necessary to create a proper proxy for that injection. It is a bug in the spec, the intention was never that, and the suggestion proposed for inject components was not included. Keep it simple, use el-resolver for that always. regards, Leonardo Uribe 2017-09-01 12:41 GMT-05:00 Gerhard Petracek : > hi paul, > > yes - imo it's the only useful alternative since the spec. prohibits the > implementation via el-resolver (for whatever reason...). > (at least there isn't an approach without issues.) > > + imo we should consider a config-parameter to activate the el-resolver i= n > any case... > > regards, > gerhard > > > > 2017-09-01 17:59 GMT+02:00 Paul Nicolucci : > >> Hi Gerhard, >> >> Thanks for the clarification. So you think MyFaces should use @Dependent >> instead of @FacesScoped and then document to ensure users are aware of t= he >> pitfalls of it? >> >> This seems to allow us to abide by the specification as well as educate >> our users. >> >> Regards, >> >> Paul Nicolucci >> >> [image: Inactive hide details for Gerhard Petracek ---09/01/2017 11:43:2= 8 >> AM---hi paul, in this (unfortunate) case the only (simple) op]Gerhard >> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case >> the only (simple) option is a producer-method >> >> From: Gerhard Petracek >> To: MyFaces Development >> Date: 09/01/2017 11:43 AM >> >> Subject: Re: JSF 2.3: Scopes of new CDI artifact in >> FacesScopeObjectProducer >> ------------------------------ >> >> >> >> hi paul, >> >> in this (unfortunate) case the only (simple) option is a producer-method >> with @Dependent instead of @FacesScoped (which doesn't make sense at all= ). >> + we have to document that users have to be careful (if they believe tha= t >> they need to use it). >> i still don't really see the use-case outside the context of the >> component itself and artifacts like validators have access to the curren= t >> component anyway. >> >> regards, >> gerhard >> >> >> >> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com* >> >: >> >> It looks like the JSF 2.3 spec says the following about this: >> >> 5.6.3 CDI for EL Resolution >> If the any of the managed beans in the application have the >> @javax.faces.annotation.FacesConfig >> annotation, the ImplicitObjectELResolver from Section 5.6.2.1 >> =E2=80=9CImplicit Object ELResolver for Facelets and >> Programmatic Access=E2=80=9D is not present in the chain. Instead, CD= I is >> used to perform EL resolution in the same manner is >> in Section TABLE 5-11 =E2=80=9CImplicitObjectELResolver for Programma= tic >> Access=E2=80=9D with the following additional implicit >> objects: >> ? externalContext >> ? the current ExternalContext from the current FacesContext >> >> This to me means that if you have the @FacesConfig annotation in your >> app the Implicit ELResolver is not available and we need to use CDI t= o >> perform the implicit object lookup. So I don't think we can depend on= the >> ELResolver in this instance. >> >> Regards, >> >> Paul Nicolucci >> >> >> [image: Inactive hide details for Gerhard Petracek ---09/01/2017 >> 09:17:05 AM---yes - there are some cases which would break with inter= f]Gerhard >> Petracek ---09/01/2017 09:17:05 AM---yes - there are some cases which= would >> break with interface-proxies and some with subclass-proxies. >> >> From: Gerhard Petracek <*gpetracek@apache.org* = > >> To: MyFaces Development <*dev@myfaces.apache.org* >> > >> Date: 09/01/2017 09:17 AM >> Subject: Re: JSF 2.3: Scopes of new CDI artifact in >> FacesScopeObjectProducer >> ------------------------------ >> >> >> >> >> yes - there are some cases which would break with interface-proxies >> and some with subclass-proxies. subclass-proxies would just support t= he >> instanceof checks used by some component-libraries, but would only wo= rk if >> just the resolved instance but not the type of the resolved instance = would >> change (per dependent-scoped subclass-proxy instance). >> >> -> therefore i (still) prefer the el-resolver (if possible). >> >> please notice that even dependent-scoped beans can cause side-effects >> here (depending on the scope of the instance which stores such a >> dependent-scoped bean). >> you could only bypass possible side-effects in this special case if >> consuming instances don't store the resolved bean + use an approach l= ike >> org.apache.deltaspike.core.api.provider.DependentProvider for them. >> -> in this case you could use injected instances only if you know all >> the implications -> resovling the instances via el-resolver is easier= ... >> >> regards, >> gerhard >> >> >> >> 2017-09-01 14:15 GMT+02:00 Thomas Andraschko < >> *andraschko.thomas@gmail.com* >: >> I fear that even proxies would not solve this problem as the >> compoent classes can be different (e.g. HtmlInputText <> HtmlCo= mmandButton). >> So the only solution is to use @Dependent which leads to worse >> performance. >> >> As you already said Gerhard, a producer doesn't make sense here= . >> Neither as a ELResolver replacement, nor for using @Inject >> UIComponent. >> >> 2017-09-01 12:25 GMT+02:00 Gerhard Petracek < >> *gpetracek@apache.org* >: >> @thomas: +1 >> >> if we don't need to use producers here, we should drop them >> again. >> (if someone would use it as a kind of "component-binding", it >> would be broken in almost every case.) >> -> the el-resolver approach mentioned by thomas is the only >> reliable way here. >> if we have to keep those producers, we have a spec. issue here >> and the best chance to limit the possible side-effects to a min= imum are >> dependent-scoped instances and/or subclass-proxies which interc= ept all >> public method-calls to resolve the current instance lazily. >> >> regards, >> gerhard >> >> >> >> 2017-09-01 9:42 GMT+02:00 Thomas Andraschko < >> *andraschko.thomas@gmail.com* >: >> Hi, >> >> i just checked the FacesScopeObjectProducer: >> >> @Produces >> @Named("component") >> @FacesScoped >> public UIComponent getComponent() >> { >> return UIComponent.getCurrentComponen >> t(FacesContext.getCurrentInstance()); >> } >> >> @Produces >> @Named("cc") >> @FacesScoped >> public UIComponent getCompositeComponent() >> { >> return UIComponent.getCurrentComposit >> eComponent(FacesContext.getCurrentInstance()); >> } >> >> I wonder if this is this the right scope for it? >> Shoudln't it be @Dependendent as the component changes >> multiple times? >> Not sure about the performance then... I think it would >> be perform much slower as in 2.2. >> Does 2.3 force us to use @Named instead ElResolver for it= ? >> >> Regards, >> Thomas >> >> >> >> >> >> > --001a114901a43c3a320558245070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

Use producers won't work. The re= ason? it is necessary to create a proper proxy for that injection. It is a = bug in the spec, the intention was never that, and the suggestion proposed = for inject components was not included.

Keep it si= mple, use el-resolver for that always.

regards,

Leonardo Uribe

2017-09-01 12:41 GMT-05:00 Gerhard Petracek= <gpetracek@apache.org>:
hi paul,

yes - imo it&= #39;s the only useful alternative since the spec. prohibits the implementat= ion via el-resolver (for whatever reason...).
(at least there isn't = an approach without issues.)

+ imo we should consider a config-param= eter to activate the el-resolver in any case...

regards,
gerhard



2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnicoluc@us.ibm.com= >:

Hi = Gerhard,

Thanks for the clarification. So yo= u think MyFaces should use @Dependent instead of @FacesScoped and then docu= ment to ensure users are aware of the pitfalls of it?

This seems to allow us to abide by the specification as well as e= ducate our users.

Regards,

Paul Nicolucci

=3D"InactiveGerhard Petracek ---09/01/2017 11:43:28 AM---hi paul, in = this (unfortunate) case the only (simple) option is a producer-method

From: Gerhard Petracek <gpetracek@apache.org>
To: MyFaces Development <<= a href=3D"mailto:dev@myfaces.apache.org" target=3D"_blank">dev@myfaces.apac= he.org>
Date: = 09/01/2017 11:43 AM


Subjec= t: Re: JSF 2.3: Scopes of new CDI artifact i= n FacesScopeObjectProducer



hi paul,

in this = (unfortunate) case the only (simple) option is a producer-method with @Depe= ndent instead of @FacesScoped (which doesn't make sense at all).
+ w= e have to document that users have to be careful (if they believe that they= need to use it).
i still don't really see the use-case outside the = context of the component itself and artifacts like validators have access t= o the current component anyway.

regards,
gerhard



2= 017-09-01 15:33 GMT+02:00 Paul Nicolucci <pnicoluc@us.ibm.com>:
    It looks like the JSF 2.3 spec says the following abou= t this:

    5.6.3 CDI for EL Resolution
    If the any of the managed beans in the application have = the @javax.faces.annotation.FacesConfig
    annotation, the ImplicitObj= ectELResolver from Section 5.6.2.1 =E2=80=9CImplicit Object ELResolver for = Facelets and
    Programmatic Access=E2=80=9D is not present in the chain. I= nstead, CDI is used to perform EL resolution in the same manner is
    in Se= ction TABLE 5-11 =E2=80=9CImplicitObjectELResolver for Programmatic Access= =E2=80=9D with the following additional implicit
    objects:
    ?     externalContext
    ?     the current ExternalContext from the curre= nt FacesContext

    This to me means that if you= have the @FacesConfig annotation in your app the Implicit ELResolver is no= t available and we need to use CDI to perform the implicit object lookup. S= o I don't think we can depend on the ELResolver in this instance.

    Regards,

    Paul Nico= lucci


    3D"InactiveGerhard Petrac= ek ---09/01/2017 09:17:05 AM---yes - there are some cases which would break= with interface-proxies and some with subclass-proxies.

    From:     Gerhard Petrace= k <<= font size=3D"2" color=3D"#0000FF">gpetracek@apache.org    >
    To:     MyFaces Development <dev@myf= aces.apache.org>
    Date:     09/01/2017 09:17 AM
    Subject:     = Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer<= br>




    yes= - there are some cases which would break with interface-proxies and some w= ith subclass-proxies. subclass-proxies would just support the instanceof ch= ecks used by some component-libraries, but would only work if just the reso= lved=C2=A0instance but not the type of the resolved=C2=A0instance would cha= nge (per dependent-scoped subclass-proxy instance).

    -> therefore = i (still) prefer the el-resolver (if possible).

    please notice that e= ven dependent-scoped beans can cause side-effects here (depending on the sc= ope of the instance which stores such a dependent-scoped bean).
    you coul= d only bypass possible side-effects in this special case if consuming insta= nces don't store the resolved bean + use an approach like org.apache.de= ltaspike.core.api.provider.DependentProvider for them.
    -> in thi= s case you could use injected instances only if you know all the implicatio= ns -> resovling the instances via el-resolver is easier...

    regard= s,
    gerhard



    2017-09-01 14:15 GMT+02:00 Thomas Andraschko &= lt;andraschko.thomas@gmail.com    >:=20
        I fear that even proxies would not solve this problem as the compoe= nt classes can be different (e.g. HtmlInputText <> HtmlCommandButton)= .
        So the only solution is to use @Dependent which leads to worse perform= ance.

        As you already said Gerhard, a producer doesn't make sense= here.
        Neither as a ELResolver replacement, nor for using @Inject UIComp= onent.

        2017-09-01 12:25 GMT+02:00 Gerhard Petracek <gpe= tracek@apache.org>:
        @thomas: +1

        if we don't= need to use producers here, we should drop them again.
        (if someone woul= d use it as a kind of "component-binding", it would be broken in = almost every case.)
        -> the el-resolver approach mentioned by thomas i= s the only reliable way here.
        if we have to keep those producers, we hav= e a spec. issue here and the best chance to limit the possible side-effects= to a minimum are dependent-scoped instances and/or subclass-proxies which = intercept all public method-calls to resolve the current instance lazily.
        regards,
        gerhard



        2017-09-01 9:42 GMT+02:00 Thomas = Andraschko <andraschko.thomas@gmail.com&= gt;:=20
            Hi,

            i just checked the FacesScopeObjectProducer:

            =C2= =A0=C2=A0 @Produces
            =C2=A0=C2=A0 @Named("component")
            =C2=A0= =C2=A0 @FacesScoped
            =C2=A0=C2=A0 public UIComponent getComponent()
            = =C2=A0=C2=A0 {
            =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return UIComponent.g= etCurrentComponent(FacesContext.getCurrentInstance());
            =C2=A0= =C2=A0 }
            =C2=A0=C2=A0
            =C2=A0=C2=A0 @Produces
            =C2=A0=C2=A0 @Named(= "cc")
            =C2=A0=C2=A0 @FacesScoped
            =C2=A0=C2=A0 public UICompo= nent getCompositeComponent()
            =C2=A0=C2=A0 {
            =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 return UIComponent.getCurrentCompositeComponent(FacesCont= ext.getCurrentInstance());
            =C2=A0=C2=A0 }

            I wonder if this i= s this the right scope for it?
            Shoudln't it be @Dependendent as the = component changes multiple times?
            Not sure about the performance then...= I think it would be perform much slower as in 2.2.
            Does 2.3 force us to= use @Named instead ElResolver for it?

            Regards,
            Thomas
        <= /ul>






--001a114901a43c3a320558245070-- --001a114901a43c3a340558245071 Content-Type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <1__=8FBB0B1DDFC420FD8f9e8a93df938690918c8FB@> X-Attachment-Id: 20450687ab03f290_0.1 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --001a114901a43c3a340558245071--