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