myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gpetra...@apache.org>
Subject Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
Date Fri, 01 Sep 2017 13:16:36 GMT
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 <andraschko.thomas@gmail.com>:

> 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 <gpetracek@apache.org>:
>
>> @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 <andraschko.thomas@gmail.com>
>> :
>>
>>> 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
>>>
>>
>>
>

Mime
View raw message