+1 will change it 2017-09-02 13:17 GMT+02:00 Gerhard Petracek <[email protected]>:
> @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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> >
