@thomas: +1 btw. FacesScopedContextImpl contains methods called #getFlowScopeBeanHolder instead of #getFacesScopeBeanHolder
regards, gerhard 2017-09-02 13:00 GMT+02:00 Thomas Andraschko <[email protected]>: > thats what i thought :) I think the correct scope is @FacesScoped. > > 2017-09-02 12:58 GMT+02:00 Gerhard Petracek <[email protected]>: > >> 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.getCurrentInstanc >>> e().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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> >
