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 Sat, 02 Sep 2017 10:37:56 GMT
@leo:

that's correct (that you won't get a proxy per default).
that's why i suggested a manual subclass-proxy initially (subclass of the
most concrete component-class based on the lookup in the producer),
however, as mentioned before it would break once the type of the resolved
component changes in a subsequent lookup within the subclass-proxy (in
dynamic constellations) and not just the instance + e.g. a component
library uses an instanceof check. that's a rare constellation, but at least
possible in theory.
-> since all approaches with producers have at least one issue (when it
comes to injection) and there isn't really a benefit imo (compared to an
el-resolver), you could just go with the simpler solution (which introduces
less overhead). furthermore, if you just do a lazy-lookup (instead of
injecting/storing the result), you won't see a (logical) issue at all. in
the end it's the same as if you get the result from an el-resolver. the
only difference to an el-resolver (in this case) is that you could inject
the result which can lead to a side-effect (-> if you don't use injection,
you get the same result).

in any case, just using a context which leads to a proxy is just wrong and
breaks in even more cases.
(only a component-context would work, but there would be the same issue as
with a manual subclass-proxy and the implementation would introduce
a significant overhead.)

regards,
gerhard



2017-09-01 21:10 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:

> Hi Gerhard
>
> It was a point discussed in the EG mailing list. @Dependent doesn't work
> because it means there is no proper proxy, and you need one that isolates
> the bean from the component.
>
> regards,
>
> Leonardo Uribe
>
> 2017-09-01 13:37 GMT-05:00 Gerhard Petracek <gpetracek@apache.org>:
>
>> @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