myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Nicolucci" <>
Subject Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
Date Fri, 01 Sep 2017 13:33:09 GMT
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
annotation, the ImplicitObjectELResolver from Section “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
? 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.


Paul Nicolucci

From:	Gerhard Petracek <>
To:	MyFaces Development <>
Date:	09/01/2017 09:17 AM
Subject:	Re: JSF 2.3: Scopes of new CDI artifact in

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


2017-09-01 14:15 GMT+02:00 Thomas Andraschko <>:
  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

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


   2017-09-01 9:42 GMT+02:00 Thomas Andraschko <

     i just checked the FacesScopeObjectProducer:

        public UIComponent getComponent()
            return UIComponent.getCurrentComponent

        public UIComponent getCompositeComponent()
            return UIComponent.getCurrentCompositeComponent

     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?


View raw message