myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <andraschko.tho...@gmail.com>
Subject Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
Date Sat, 02 Sep 2017 11:19:54 GMT
+1 will change it

2017-09-02 13:17 GMT+02:00 Gerhard Petracek <gpetracek@apache.org>:

> @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