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 18:37:03 GMT
@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 <lu4242@gmail.com>:

> 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