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 <[email protected]>: > 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >
