+1 for ignoring it for now and open a spec issue Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
> @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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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] >>> <javascript:_e(%7B%7D,'cvml','[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] >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> >>>> To: MyFaces Development <[email protected] >>>> <javascript:_e(%7B%7D,'cvml','[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]* >>>> <javascript:_e(%7B%7D,'cvml','[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]* >>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> >>>> To: MyFaces Development <*[email protected]* >>>> <javascript:_e(%7B%7D,'cvml','[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]* >>>> <javascript:_e(%7B%7D,'cvml','[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]* >>>> <javascript:_e(%7B%7D,'cvml','[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]* >>>> <javascript:_e(%7B%7D,'cvml','[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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
