Hi Leonardo,
If we let CDI handle the EL resolving of #{facesContext} it does not
imply in any form or shape that the JSF runtime is not in control of
creating the FacesContext. All it means is that when you have a
#{facesContext} EL expression it will use the CDI FacesContextProducer
to get the FacesContext.
Regards,
Manfred
On 10/6/14, 4:11 PM, Leonardo Uribe wrote:
> 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