+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.tho...@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 <lu4...@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 <gpetra...@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 <pnico...@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 <gpetra...@apache.org>
>>>>> To: MyFaces Development <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 <*pnico...@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 <*gpetra...@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.tho...@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 <
>>>>> *gpetra...@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.tho...@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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
