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 <[email protected]>:
> +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 <[email protected]>
> :
>
>> +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 <[email protected]>:
>>>
>>>> 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 <[email protected]>:
>>>>
>>>>> 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 <[email protected]>:
>>>>>
>>>>>> 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 <[email protected]>
>>>>>> To: MyFaces Development <[email protected]>
>>>>>> 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 <*[email protected]*>:
>>>>>>
>>>>>> 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 <*[email protected]*>
>>>>>> To: MyFaces Development <*[email protected]*>
>>>>>> 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 <
>>>>>> *[email protected]*>:
>>>>>> 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 <
>>>>>> *[email protected]*>:
>>>>>> @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 <
>>>>>> *[email protected]*>:
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
