Hi Manfred
I see. So JSF EL Resolver still resolves FacesContext EL expression,
but this times it will call CDI to get the right instance. That sounds
good. Note we have here a problem between JSF, EL and CDI. JSF has
been always on top using EL,and CDI provides an EL resolver. So, the
sequence has been always from JSF to EL to CDI. But now we will call
CDI "under the hood" (maybe through BeanManager), which means that we
bypass CDI EL Resolver for an special case like this.
I know there is a problem between JSF and CDI. We want that CDI takes
control over some objects, like converters or validators or anything,
so we can use @Inject all over the place and keep things running. I
suppose we will need something like this a couple of times more.
regards,
Leonardo
2014-10-06 16:37 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> Hi Leonardo,
>
> The table itself is still valid, the only difference is the underlying
> implementation, so we would have to make adjustments to reflect that. So no
> it would not be moved to CDI specification as CDI would be the enabler for
> this functionality, but the JSF runtime is still the implementer.
>
> Regards,
> Manfred
>
>
> On 10/6/14, 4:22 PM, Leonardo Uribe wrote:
>>
>> Hi
>>
>> I forgot to mention that if you let CDI handle #{facesContext}, what about
>> #{viewRoot} or #{session} or all other objects that rely on FacesContext
>> to be found? We have already big table in the spec that relies on that
>> and if you take a look at the code the entry point is always FacesContext.
>> Will this table be removed from JSF spec and moved to CDI?
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>
>> 2014-10-06 16:11 GMT-05:00 Leonardo Uribe<leonardo.uribe_at_irian.at>:
>>>
>>> Hi Ed
>>>
>>> But still the change discussed here (let CDI manage #{facesContext} )
>>> has its problems.
>>>
>>> Right now we have these methods:
>>>
>>> FacesContext.getCurrentInstance();
>>> // protected
>>> FacesContext.setCurrentInstance(FacesContext instance);
>>> FacesContext.getELContext();
>>>
>>> The problem is this: In JSF we are used to call
>>> FacesContext.getCurrentInstance(), but on the ELResolver we take
>>> the FacesContext instance from the ELContext. Yes, there is a
>>> circular reference here. The default implementation of FacesContext
>>> wraps ELContext and add the reference. That is preferred, because
>>> it avoids calls to FacesContext.getCurrentInstance().
>>>
>>> Who knows this detail? JSF. Who is responsible for create and
>>> destroy FacesContext? JSF. Who should have control over how
>>> #{facesContext} is resolved? JSF.
>>>
>>> I don't see difficult to provide a CDI extension inside JSF to deal
>>> with FacesContext problem. The only thing you need to realize is
>>> you can use a wrapper or proxy, so the instance in the bean should
>>> not be the same instance. To get the inner instance you can always
>>> use getWrapped() method.
>>>
>>> I know it is easier just to burn the code inside CDI, but my question is
>>> if this has really sense or not, from a design perspective. It just
>>> sounds
>>> too inconvenient for me, because you are losing a lot of flexibility
>>> in the implementation, and this is not something you must do inside
>>> CDI, it is something where we can choose, and if we have an option,
>>> why don't choose keep it under JSF control?.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2014-10-06 15:16 GMT-05:00 Edward Burns<edward.burns_at_oracle.com>:
>>>>>>>>>
>>>>>>>>> On Mon, 6 Oct 2014 14:35:58 -0500, Leonardo
>>>>>>>>> Uribe<leonardo.uribe_at_irian.at> said:
>>>>
>>>> LU> The problem is we introduce a dependency in CDI for JSF, unless we
>>>> get
>>>>
>>>> Well, we're not *introducing* a dependency. We are adding more weight
>>>> to a dependency we already have.
>>>>
>>>> LU> There is no real advantage to do that. As far as I remember, CDI is
>>>> an
>>>> LU> optional dependency, even if there are classes in JSF that use CDI
>>>> LU> api, you can run JSF without CDI. Does that will change with JSF
>>>> 2.3?
>>>>
>>>> You are right that prior to JSF 2.3, it was possible to use a subset of
>>>> JSF features on containers that did not provide CDI. We are indeed
>>>> proposing to change that in JSF 2.3, making CDI required. This change
>>>> is most strongly articulated in [1287-RedefineManagedBeansAsCDIBeans].
>>>> In addition to this change, we are also requiring Java EE 8 and Java SE
>>>> 8 in order to run JSF 2.3.
>>>>
>>>> We realize these two changes are departures to our decade old policy of
>>>> lagging one version behind the platform. We reasoned that if people
>>>> have stuck with JSF for this long, they would be willing to move up to
>>>> EE 8 as well.
>>>>
>>>> LU> I think CDI provides a pluggable API that works for our needs. The
>>>> LU> only thing that I miss about that API is that you can't control
>>>> class
>>>> LU> scanning, and that causes problems because application servers
>>>> LU> sometimes need to customize that part.
>>>>
>>>> Yes, this is one of those areas that CDI hasn't fully addressed yet.
>>>> However, we believe we can mitigate the impact of this by not even
>>>> saying anything about CDI's pluggable API.
>>>>
>>>> Ed
>>>> --
>>>> | edward.burns_at_oracle.com | office: +1 407 458 0017
>>>> | 24 work days til Devoxx 2014