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:58:19 GMT
hi thomas,

+1 - that's wrong as well (since #getCurrentFlowScope just returns the
ConcurrentHashMap used internally).
it would just work if the producer returns a "proxy-map" which is using
lazy-delegation.

regards,
gerhard



2017-09-02 10:10 GMT+02:00 Thomas Andraschko <andraschko.thomas@gmail.com>:

> Will work on it now.
>
> What about this one:
>    @Produces
>    @Named("flowScope")
>    @FlowMap
>    @ApplicationScoped
>    public Map<Object, Object> getFlowMap()
>    {
>       return FacesContext.getCurrentInstance().getApplication().
> getFlowHandler().getCurrentFlowScope();
>    }
>
> Is it really correct to produce this into ApplicationScoped?
>
> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu4242@gmail.com>:
>
>> +1 for ignore. @ResolveComponent is still the closest solution we could
>> have. That is MyFaces Core specific feature, at least in my mind.
>>
>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <andraschko.thomas@gmail.com
>> >:
>>
>>> +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 <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*>:
>>>>>>>
>>>>>>>    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*>
>>>>>>>    To: MyFaces Development <*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*>:
>>>>>>>       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