myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
Date Fri, 01 Sep 2017 17:44:30 GMT
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 <gpetracek@apache.org>:

> 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 <pnicoluc@us.ibm.com>:
>
>> 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 <gpetracek@apache.org>
>> To: MyFaces Development <dev@myfaces.apache.org>
>> 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 <*pnicoluc@us.ibm.com*
>> <pnicoluc@us.ibm.com>>:
>>
>>    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 <*gpetracek@apache.org* <gpetracek@apache.org>>
>>    To: MyFaces Development <*dev@myfaces.apache.org*
>>    <dev@myfaces.apache.org>>
>>    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 <
>>    *andraschko.thomas@gmail.com* <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* <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* <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