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 >>> >> >> >
