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 11:17:34 GMT
@thomas: +1
btw. FacesScopedContextImpl contains methods called #getFlowScopeBeanHolder
instead of #getFacesScopeBeanHolder

regards,
gerhard



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

> thats what i thought :) I think the correct scope is @FacesScoped.
>
> 2017-09-02 12:58 GMT+02:00 Gerhard Petracek <gpetracek@apache.org>:
>
>> 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.getCurrentInstanc
>>> e().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