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.getCurrentInstance().getApplication().getFlowHa >> ndler().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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >
