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