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.getCurrentComponent(FacesContext. > getCurrentInstance()); > } > > @Produces > @Named("cc") > @FacesScoped > public UIComponent getCompositeComponent() > { > return UIComponent.getCurrentCompositeComponent( > 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 > > > > > >
