@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]* >>> <[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 >>> >>> >>> >>> >>> >>> >> >
