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 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 Inactive hide details for Gerhard Petracek ---09/01/2017 09:17:05 AM---yes - there are some cases which would break with interfGerhard 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.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
