You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Thomas Andraschko <an...@gmail.com> on 2017/09/01 07:42:52 UTC

JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Hi,

i just checked the FacesScopeObjectProducer:

   @Produces
   @Named("component")
   @FacesScoped
   public UIComponent getComponent()
   {
       return
UIComponent.getCurrentComponent(FacesContext.getCurrentInstance());
   }

   @Produces
   @Named("cc")
   @FacesScoped
   public UIComponent getCompositeComponent()
   {
       return
UIComponent.getCurrentCompositeComponent(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

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Thomas Andraschko <an...@gmail.com>.
+1 will change it

2017-09-02 13:17 GMT+02:00 Gerhard Petracek <gp...@apache.org>:

> @thomas: +1
> btw. FacesScopedContextImpl contains methods called
> #getFlowScopeBeanHolder instead of #getFacesScopeBeanHolder
>
> regards,
> gerhard
>
>
>
> 2017-09-02 13:00 GMT+02:00 Thomas Andraschko <an...@gmail.com>
> :
>
>> thats what i thought :) I think the correct scope is @FacesScoped.
>>
>> 2017-09-02 12:58 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
>>
>>> hi thomas,
>>>
>>> +1 - that's wrong as well (since #getCurrentFlowScope just returns the
>>> ConcurrentHashMap used internally).
>>> it would just work if the producer returns a "proxy-map" which is using
>>> lazy-delegation.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-02 10:10 GMT+02:00 Thomas Andraschko <
>>> andraschko.thomas@gmail.com>:
>>>
>>>> Will work on it now.
>>>>
>>>> What about this one:
>>>>    @Produces
>>>>    @Named("flowScope")
>>>>    @FlowMap
>>>>    @ApplicationScoped
>>>>    public Map<Object, Object> getFlowMap()
>>>>    {
>>>>       return FacesContext.getCurrentInstanc
>>>> e().getApplication().getFlowHandler().getCurrentFlowScope();
>>>>    }
>>>>
>>>> Is it really correct to produce this into ApplicationScoped?
>>>>
>>>> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>>
>>>>> +1 for ignore. @ResolveComponent is still the closest solution we
>>>>> could have. That is MyFaces Core specific feature, at least in my mind.
>>>>>
>>>>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <
>>>>> andraschko.thomas@gmail.com>:
>>>>>
>>>>>> +1 for ignoring it for now and open a spec issue
>>>>>>
>>>>>>
>>>>>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>>>>>
>>>>>>> @leo:
>>>>>>>
>>>>>>> as i said: "...we have a spec. issue here..."
>>>>>>> if we have to follow it, we need to use @Dependent.
>>>>>>>
>>>>>>> if there isn't a tck-test for it, we could even ignore the written
>>>>>>> spec. (that isn't nice, but mojarra is also doing it in some cases...).
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>>>>>
>>>>>>>> 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 <gp...@apache.org>:
>>>>>>>>
>>>>>>>>> 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 in any case...
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> gerhard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>>>>>
>>>>>>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>>>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>>>>>>> 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 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 to the current
>>>>>>>>>> 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
>>>>>>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>>>>>>    Programmatic Access” is not present in the chain. Instead,
>>>>>>>>>>    CDI is used to perform EL resolution in the same manner is
>>>>>>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for
>>>>>>>>>>    Programmatic Access” 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
>>>>>>>>>>    to 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 interf]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 the instanceof checks used by some component-libraries, but
>>>>>>>>>>    would only work 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
>>>>>>>>>>    like 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 <>
>>>>>>>>>>          HtmlCommandButton).
>>>>>>>>>>          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
>>>>>>>>>>          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*>:
>>>>>>>>>>             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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
@thomas: +1
btw. FacesScopedContextImpl contains methods called #getFlowScopeBeanHolder
instead of #getFacesScopeBeanHolder

regards,
gerhard



2017-09-02 13:00 GMT+02:00 Thomas Andraschko <an...@gmail.com>:

> thats what i thought :) I think the correct scope is @FacesScoped.
>
> 2017-09-02 12:58 GMT+02:00 Gerhard Petracek <gp...@apache.org>:
>
>> hi thomas,
>>
>> +1 - that's wrong as well (since #getCurrentFlowScope just returns the
>> ConcurrentHashMap used internally).
>> it would just work if the producer returns a "proxy-map" which is using
>> lazy-delegation.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-02 10:10 GMT+02:00 Thomas Andraschko <andraschko.thomas@gmail.com
>> >:
>>
>>> Will work on it now.
>>>
>>> What about this one:
>>>    @Produces
>>>    @Named("flowScope")
>>>    @FlowMap
>>>    @ApplicationScoped
>>>    public Map<Object, Object> getFlowMap()
>>>    {
>>>       return FacesContext.getCurrentInstanc
>>> e().getApplication().getFlowHandler().getCurrentFlowScope();
>>>    }
>>>
>>> Is it really correct to produce this into ApplicationScoped?
>>>
>>> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>
>>>> +1 for ignore. @ResolveComponent is still the closest solution we could
>>>> have. That is MyFaces Core specific feature, at least in my mind.
>>>>
>>>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <
>>>> andraschko.thomas@gmail.com>:
>>>>
>>>>> +1 for ignoring it for now and open a spec issue
>>>>>
>>>>>
>>>>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>>>>
>>>>>> @leo:
>>>>>>
>>>>>> as i said: "...we have a spec. issue here..."
>>>>>> if we have to follow it, we need to use @Dependent.
>>>>>>
>>>>>> if there isn't a tck-test for it, we could even ignore the written
>>>>>> spec. (that isn't nice, but mojarra is also doing it in some cases...).
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>>>>
>>>>>>> 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 <gp...@apache.org>:
>>>>>>>
>>>>>>>> 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 in any case...
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>>>>
>>>>>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>>>>>> 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 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 to the current
>>>>>>>>> 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
>>>>>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>>>>>    Programmatic Access” is not present in the chain. Instead, CDI
>>>>>>>>>    is used to perform EL resolution in the same manner is
>>>>>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for
>>>>>>>>>    Programmatic Access” 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
>>>>>>>>>    to 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 interf]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 the instanceof checks used by some component-libraries, but
>>>>>>>>>    would only work 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
>>>>>>>>>    like 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 <>
>>>>>>>>>          HtmlCommandButton).
>>>>>>>>>          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
>>>>>>>>>          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*>:
>>>>>>>>>             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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Thomas Andraschko <an...@gmail.com>.
thats what i thought :) I think the correct scope is @FacesScoped.

2017-09-02 12:58 GMT+02:00 Gerhard Petracek <gp...@apache.org>:

> hi thomas,
>
> +1 - that's wrong as well (since #getCurrentFlowScope just returns the
> ConcurrentHashMap used internally).
> it would just work if the producer returns a "proxy-map" which is using
> lazy-delegation.
>
> regards,
> gerhard
>
>
>
> 2017-09-02 10:10 GMT+02:00 Thomas Andraschko <an...@gmail.com>
> :
>
>> Will work on it now.
>>
>> What about this one:
>>    @Produces
>>    @Named("flowScope")
>>    @FlowMap
>>    @ApplicationScoped
>>    public Map<Object, Object> getFlowMap()
>>    {
>>       return FacesContext.getCurrentInstance().getApplication().getFlowHa
>> ndler().getCurrentFlowScope();
>>    }
>>
>> Is it really correct to produce this into ApplicationScoped?
>>
>> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>
>>> +1 for ignore. @ResolveComponent is still the closest solution we could
>>> have. That is MyFaces Core specific feature, at least in my mind.
>>>
>>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <
>>> andraschko.thomas@gmail.com>:
>>>
>>>> +1 for ignoring it for now and open a spec issue
>>>>
>>>>
>>>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>>>
>>>>> @leo:
>>>>>
>>>>> as i said: "...we have a spec. issue here..."
>>>>> if we have to follow it, we need to use @Dependent.
>>>>>
>>>>> if there isn't a tck-test for it, we could even ignore the written
>>>>> spec. (that isn't nice, but mojarra is also doing it in some cases...).
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>>>
>>>>>> 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 <gp...@apache.org>:
>>>>>>
>>>>>>> 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 in any case...
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>>>
>>>>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>>>>> 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 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 to the current
>>>>>>>> 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
>>>>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>>>>    Programmatic Access” is not present in the chain. Instead, CDI
>>>>>>>>    is used to perform EL resolution in the same manner is
>>>>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for
>>>>>>>>    Programmatic Access” 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
>>>>>>>>    to 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 interf]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 the instanceof checks used by some component-libraries, but
>>>>>>>>    would only work 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
>>>>>>>>    like 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 <> HtmlCommandButton).
>>>>>>>>          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 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*>:
>>>>>>>>             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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
hi thomas,

+1 - that's wrong as well (since #getCurrentFlowScope just returns the
ConcurrentHashMap used internally).
it would just work if the producer returns a "proxy-map" which is using
lazy-delegation.

regards,
gerhard



2017-09-02 10:10 GMT+02:00 Thomas Andraschko <an...@gmail.com>:

> Will work on it now.
>
> What about this one:
>    @Produces
>    @Named("flowScope")
>    @FlowMap
>    @ApplicationScoped
>    public Map<Object, Object> getFlowMap()
>    {
>       return FacesContext.getCurrentInstance().getApplication().
> getFlowHandler().getCurrentFlowScope();
>    }
>
> Is it really correct to produce this into ApplicationScoped?
>
> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>
>> +1 for ignore. @ResolveComponent is still the closest solution we could
>> have. That is MyFaces Core specific feature, at least in my mind.
>>
>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <andraschko.thomas@gmail.com
>> >:
>>
>>> +1 for ignoring it for now and open a spec issue
>>>
>>>
>>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>>
>>>> @leo:
>>>>
>>>> as i said: "...we have a spec. issue here..."
>>>> if we have to follow it, we need to use @Dependent.
>>>>
>>>> if there isn't a tck-test for it, we could even ignore the written
>>>> spec. (that isn't nice, but mojarra is also doing it in some cases...).
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>>
>>>>> 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 <gp...@apache.org>:
>>>>>
>>>>>> 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 in any case...
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>>
>>>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>>>> 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
>>>>>>> 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 to the current
>>>>>>> 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
>>>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>>>    Programmatic Access” is not present in the chain. Instead, CDI
>>>>>>>    is used to perform EL resolution in the same manner is
>>>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>>>>    Access” 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 to
>>>>>>>    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 interf]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 the instanceof checks used by some component-libraries, but
>>>>>>>    would only work 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 like
>>>>>>>    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 <> HtmlCommandButton).
>>>>>>>          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 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*>:
>>>>>>>             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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Thomas Andraschko <an...@gmail.com>.
Will work on it now.

What about this one:
   @Produces
   @Named("flowScope")
   @FlowMap
   @ApplicationScoped
   public Map<Object, Object> getFlowMap()
   {
      return
FacesContext.getCurrentInstance().getApplication().getFlowHandler().getCurrentFlowScope();
   }

Is it really correct to produce this into ApplicationScoped?

2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:

> +1 for ignore. @ResolveComponent is still the closest solution we could
> have. That is MyFaces Core specific feature, at least in my mind.
>
> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <an...@gmail.com>
> :
>
>> +1 for ignoring it for now and open a spec issue
>>
>>
>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>
>>> @leo:
>>>
>>> as i said: "...we have a spec. issue here..."
>>> if we have to follow it, we need to use @Dependent.
>>>
>>> if there isn't a tck-test for it, we could even ignore the written spec.
>>> (that isn't nice, but mojarra is also doing it in some cases...).
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>>
>>>> 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 <gp...@apache.org>:
>>>>
>>>>> 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 in any case...
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>>
>>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>>> 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
>>>>>> 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 to the current
>>>>>> 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
>>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>>>>>    used to perform EL resolution in the same manner is
>>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>>>    Access” 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 to
>>>>>>    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 interf]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 the instanceof checks used by some component-libraries, but
>>>>>>    would only work 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 like
>>>>>>    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 <> HtmlCommandButton).
>>>>>>          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 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*>:
>>>>>>             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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Leonardo Uribe <lu...@gmail.com>.
+1 for ignore. @ResolveComponent is still the closest solution we could
have. That is MyFaces Core specific feature, at least in my mind.

2017-09-01 14:08 GMT-05:00 Thomas Andraschko <an...@gmail.com>:

> +1 for ignoring it for now and open a spec issue
>
>
> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>
>> @leo:
>>
>> as i said: "...we have a spec. issue here..."
>> if we have to follow it, we need to use @Dependent.
>>
>> if there isn't a tck-test for it, we could even ignore the written spec.
>> (that isn't nice, but mojarra is also doing it in some cases...).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>
>>> 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 <gp...@apache.org>:
>>>
>>>> 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
>>>> in any case...
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>
>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>> 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
>>>>> 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 to the current
>>>>> 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
>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>>>>    used to perform EL resolution in the same manner is
>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>>    Access” 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 to
>>>>>    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 interf]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 the instanceof checks used by some component-libraries, but
>>>>>    would only work 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 like
>>>>>    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 <> HtmlCommandButton).
>>>>>          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 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*>:
>>>>>             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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Thomas Andraschko <an...@gmail.com>.
+1 for ignoring it for now and open a spec issue

Am Freitag, 1. September 2017 schrieb Gerhard Petracek :

> @leo:
>
> as i said: "...we have a spec. issue here..."
> if we have to follow it, we need to use @Dependent.
>
> if there isn't a tck-test for it, we could even ignore the written spec.
> (that isn't nice, but mojarra is also doing it in some cases...).
>
> regards,
> gerhard
>
>
>
> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4242@gmail.com
> <javascript:_e(%7B%7D,'cvml','lu4242@gmail.com');>>:
>
>> 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 <gpetracek@apache.org
>> <javascript:_e(%7B%7D,'cvml','gpetracek@apache.org');>>:
>>
>>> 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
>>> in any case...
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnicoluc@us.ibm.com
>>> <javascript:_e(%7B%7D,'cvml','pnicoluc@us.ibm.com');>>:
>>>
>>>> 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 the 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:28 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 <gpetracek@apache.org
>>>> <javascript:_e(%7B%7D,'cvml','gpetracek@apache.org');>>
>>>> To: MyFaces Development <dev@myfaces.apache.org
>>>> <javascript:_e(%7B%7D,'cvml','dev@myfaces.apache.org');>>
>>>> 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
>>>> 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 to the current
>>>> component anyway.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com*
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>>    “Implicit Object ELResolver for Facelets and
>>>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>>>    used to perform EL resolution in the same manner is
>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>    Access” 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 to
>>>>    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 interf]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*
>>>>    <javascript:_e(%7B%7D,'cvml','gpetracek@apache.org');>>
>>>>    To: MyFaces Development <*dev@myfaces.apache.org*
>>>>    <javascript:_e(%7B%7D,'cvml','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 the
>>>>    instanceof checks used by some component-libraries, but would only work 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 like
>>>>    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*
>>>>    <javascript:_e(%7B%7D,'cvml','andraschko.thomas@gmail.com');>>:
>>>>       I fear that even proxies would not solve this problem as the
>>>>          compoent classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>>>>          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*
>>>>          <javascript:_e(%7B%7D,'cvml','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 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*
>>>>          <javascript:_e(%7B%7D,'cvml','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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
@leo:

that's correct (that you won't get a proxy per default).
that's why i suggested a manual subclass-proxy initially (subclass of the
most concrete component-class based on the lookup in the producer),
however, as mentioned before it would break once the type of the resolved
component changes in a subsequent lookup within the subclass-proxy (in
dynamic constellations) and not just the instance + e.g. a component
library uses an instanceof check. that's a rare constellation, but at least
possible in theory.
-> since all approaches with producers have at least one issue (when it
comes to injection) and there isn't really a benefit imo (compared to an
el-resolver), you could just go with the simpler solution (which introduces
less overhead). furthermore, if you just do a lazy-lookup (instead of
injecting/storing the result), you won't see a (logical) issue at all. in
the end it's the same as if you get the result from an el-resolver. the
only difference to an el-resolver (in this case) is that you could inject
the result which can lead to a side-effect (-> if you don't use injection,
you get the same result).

in any case, just using a context which leads to a proxy is just wrong and
breaks in even more cases.
(only a component-context would work, but there would be the same issue as
with a manual subclass-proxy and the implementation would introduce
a significant overhead.)

regards,
gerhard



2017-09-01 21:10 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:

> Hi Gerhard
>
> It was a point discussed in the EG mailing list. @Dependent doesn't work
> because it means there is no proper proxy, and you need one that isolates
> the bean from the component.
>
> regards,
>
> Leonardo Uribe
>
> 2017-09-01 13:37 GMT-05:00 Gerhard Petracek <gp...@apache.org>:
>
>> @leo:
>>
>> as i said: "...we have a spec. issue here..."
>> if we have to follow it, we need to use @Dependent.
>>
>> if there isn't a tck-test for it, we could even ignore the written spec.
>> (that isn't nice, but mojarra is also doing it in some cases...).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>>
>>> 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 <gp...@apache.org>:
>>>
>>>> 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
>>>> in any case...
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>>
>>>>> 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 the 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:28 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 <gp...@apache.org>
>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>> 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
>>>>> 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 to the current
>>>>> component anyway.
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com*
>>>>> <pn...@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
>>>>>    “Implicit Object ELResolver for Facelets and
>>>>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>>>>    used to perform EL resolution in the same manner is
>>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>>    Access” 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 to
>>>>>    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 interf]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*
>>>>>    <gp...@apache.org>>
>>>>>    To: MyFaces Development <*dev@myfaces.apache.org*
>>>>>    <de...@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 the instanceof checks used by some component-libraries, but
>>>>>    would only work 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 like
>>>>>    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* <an...@gmail.com>>:
>>>>>       I fear that even proxies would not solve this problem as the
>>>>>          compoent classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>>>>>          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* <gp...@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 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* <an...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Gerhard

It was a point discussed in the EG mailing list. @Dependent doesn't work
because it means there is no proper proxy, and you need one that isolates
the bean from the component.

regards,

Leonardo Uribe

2017-09-01 13:37 GMT-05:00 Gerhard Petracek <gp...@apache.org>:

> @leo:
>
> as i said: "...we have a spec. issue here..."
> if we have to follow it, we need to use @Dependent.
>
> if there isn't a tck-test for it, we could even ignore the written spec.
> (that isn't nice, but mojarra is also doing it in some cases...).
>
> regards,
> gerhard
>
>
>
> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:
>
>> 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 <gp...@apache.org>:
>>
>>> 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
>>> in any case...
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>>
>>>> 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 the 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:28 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 <gp...@apache.org>
>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>> 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
>>>> 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 to the current
>>>> component anyway.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com*
>>>> <pn...@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
>>>>    “Implicit Object ELResolver for Facelets and
>>>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>>>    used to perform EL resolution in the same manner is
>>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>    Access” 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 to
>>>>    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 interf]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*
>>>>    <gp...@apache.org>>
>>>>    To: MyFaces Development <*dev@myfaces.apache.org*
>>>>    <de...@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 the
>>>>    instanceof checks used by some component-libraries, but would only work 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 like
>>>>    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* <an...@gmail.com>>:
>>>>       I fear that even proxies would not solve this problem as the
>>>>          compoent classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>>>>          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* <gp...@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 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* <an...@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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
@leo:

as i said: "...we have a spec. issue here..."
if we have to follow it, we need to use @Dependent.

if there isn't a tck-test for it, we could even ignore the written spec.
(that isn't nice, but mojarra is also doing it in some cases...).

regards,
gerhard



2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu...@gmail.com>:

> 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 <gp...@apache.org>:
>
>> 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
>> in any case...
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>>
>>> 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 the
>>> 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:28 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 <gp...@apache.org>
>>> To: MyFaces Development <de...@myfaces.apache.org>
>>> 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
>>> 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 to the current
>>> component anyway.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com*
>>> <pn...@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
>>>    “Implicit Object ELResolver for Facelets and
>>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>>    used to perform EL resolution in the same manner is
>>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>    Access” 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 to
>>>    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 interf]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* <gp...@apache.org>
>>>    >
>>>    To: MyFaces Development <*dev@myfaces.apache.org*
>>>    <de...@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 the
>>>    instanceof checks used by some component-libraries, but would only work 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 like
>>>    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* <an...@gmail.com>>:
>>>       I fear that even proxies would not solve this problem as the
>>>          compoent classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>>>          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* <gp...@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 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* <an...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Leonardo Uribe <lu...@gmail.com>.
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 <gp...@apache.org>:

> 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 in
> any case...
>
> regards,
> gerhard
>
>
>
> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pn...@us.ibm.com>:
>
>> 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 the
>> 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:28
>> 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 <gp...@apache.org>
>> To: MyFaces Development <de...@myfaces.apache.org>
>> 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 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 to the current
>> component anyway.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com*
>> <pn...@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
>>    “Implicit Object ELResolver for Facelets and
>>    Programmatic Access” is not present in the chain. Instead, CDI is
>>    used to perform EL resolution in the same manner is
>>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>    Access” 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 to
>>    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 interf]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* <gp...@apache.org>>
>>    To: MyFaces Development <*dev@myfaces.apache.org*
>>    <de...@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 the
>>    instanceof checks used by some component-libraries, but would only work 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 like
>>    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* <an...@gmail.com>>:
>>       I fear that even proxies would not solve this problem as the
>>          compoent classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>>          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* <gp...@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 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* <an...@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
>>
>>
>>
>>
>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
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 in
any case...

regards,
gerhard



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

> 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 the
> 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:28
> 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 <gp...@apache.org>
> To: MyFaces Development <de...@myfaces.apache.org>
> 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 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 to the current component
> anyway.
>
> regards,
> gerhard
>
>
>
> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnicoluc@us.ibm.com*
> <pn...@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
>    “Implicit Object ELResolver for Facelets and
>    Programmatic Access” is not present in the chain. Instead, CDI is used
>    to perform EL resolution in the same manner is
>    in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>    Access” 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 to
>    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 interf]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* <gp...@apache.org>>
>    To: MyFaces Development <*dev@myfaces.apache.org*
>    <de...@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 the
>    instanceof checks used by some component-libraries, but would only work 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 like
>    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* <an...@gmail.com>>:
>       I fear that even proxies would not solve this problem as the
>          compoent classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>          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* <gp...@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 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* <an...@gmail.com>>:
>             Hi,
>
>                i just checked the FacesScopeObjectProducer:
>
>                   @Produces
>                   @Named("component")
>                   @FacesScoped
>                   public UIComponent getComponent()
>                   {
>                       return UIComponent.getCurrentComponent(FacesContext.
>                getCurrentInstance());
>                   }
>
>                   @Produces
>                   @Named("cc")
>                   @FacesScoped
>                   public UIComponent getCompositeComponent()
>                   {
>                       return UIComponent.getCurrentCompositeComponent(
>                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
>
>
>
>
>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Paul Nicolucci <pn...@us.ibm.com>.
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 the
pitfalls of it?

This seems to allow us to abide by the specification as well as educate our
users.

Regards,

Paul Nicolucci



From:	Gerhard Petracek <gp...@apache.org>
To:	MyFaces Development <de...@myfaces.apache.org>
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 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 to the current component
anyway.

regards,
gerhard



2017-09-01 15:33 GMT+02:00 Paul Nicolucci <pn...@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 “Implicit
  Object ELResolver for Facelets and
  Programmatic Access” is not present in the chain. Instead, CDI is used to
  perform EL resolution in the same manner is
  in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic Access”
  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 to
  perform the implicit object lookup. So I don't think we can depend on the
  ELResolver in this instance.

  Regards,

  Paul Nicolucci


  Inactive hide details for Gerhard Petracek ---09/01/2017 09:17:05
  AM---yes - there are some cases which would break with interfGerhard
  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 <gp...@apache.org>
  To: MyFaces Development <de...@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 the
  instanceof checks used by some component-libraries, but would only work
  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 like
  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 <>
        HtmlCommandButton).
        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 <gp...@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 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>:
              Hi,

              i just checked the FacesScopeObjectProducer:

                 @Produces
                 @Named("component")
                 @FacesScoped
                 public UIComponent getComponent()
                 {
                     return UIComponent.getCurrentComponent
              (FacesContext.getCurrentInstance());
                 }

                 @Produces
                 @Named("cc")
                 @FacesScoped
                 public UIComponent getCompositeComponent()
                 {
                     return UIComponent.getCurrentCompositeComponent
              (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

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
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 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 to the current component
anyway.

regards,
gerhard



2017-09-01 15:33 GMT+02:00 Paul Nicolucci <pn...@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 “Implicit
> Object ELResolver for Facelets and
> Programmatic Access” is not present in the chain. Instead, CDI is used to
> perform EL resolution in the same manner is
> in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic Access”
> 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 to 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 interf]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 <gp...@apache.org>
> To: MyFaces Development <de...@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 the
> instanceof checks used by some component-libraries, but would only work 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 like
> 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* <an...@gmail.com>>:
>
>    I fear that even proxies would not solve this problem as the compoent
>    classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>    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*
>    <gp...@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 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* <an...@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
>
>
>
>
>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Paul Nicolucci <pn...@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 “Implicit
Object ELResolver for Facelets and
Programmatic Access” is not present in the chain. Instead, CDI is used to
perform EL resolution in the same manner is
in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic Access”
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 to perform
the implicit object lookup. So I don't think we can depend on the
ELResolver in this instance.

Regards,

Paul Nicolucci




From:	Gerhard Petracek <gp...@apache.org>
To:	MyFaces Development <de...@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 the
instanceof checks used by some component-libraries, but would only work 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 like
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 <an...@gmail.com>:
  I fear that even proxies would not solve this problem as the compoent
  classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
  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 <gp...@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 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
   >:
     Hi,

     i just checked the FacesScopeObjectProducer:

        @Produces
        @Named("component")
        @FacesScoped
        public UIComponent getComponent()
        {
            return UIComponent.getCurrentComponent
     (FacesContext.getCurrentInstance());
        }

        @Produces
        @Named("cc")
        @FacesScoped
        public UIComponent getCompositeComponent()
        {
            return UIComponent.getCurrentCompositeComponent
     (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

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@apache.org>.
yes - there are some cases which would break with interface-proxies and
some with subclass-proxies. subclass-proxies would just support the
instanceof checks used by some component-libraries, but would only work 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 like
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 <an...@gmail.com>:

> I fear that even proxies would not solve this problem as the compoent
> classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
> 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 <gp...@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 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 <an...@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
>>>
>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Thomas Andraschko <an...@gmail.com>.
I fear that even proxies would not solve this problem as the compoent
classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
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 <gp...@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 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 <an...@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
>>
>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

Posted by Gerhard Petracek <gp...@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 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 <an...@gmail.com>:

> Hi,
>
> i just checked the FacesScopeObjectProducer:
>
>    @Produces
>    @Named("component")
>    @FacesScoped
>    public UIComponent getComponent()
>    {
>        return UIComponent.getCurrentComponent(FacesContext.
> getCurrentInstance());
>    }
>
>    @Produces
>    @Named("cc")
>    @FacesScoped
>    public UIComponent getCompositeComponent()
>    {
>        return UIComponent.getCurrentCompositeComponent(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
>