Hi all,
I have turned on the CDI EL resolver for #{facesContext} and I have done
the following changes in the specification
The following changes were added to the spec:
ADDED
As part of a continued effort of aligning the JSF specification with the
CDI specification the EL resolver added by the CDI runtime will play a
more important role in doing EL resolving. As such the following table
states which JSF artifacts will be resolved by means of CDI producers:
JSF Artifact Backing JSF methods
FacesContext FacesContext.getCurrentInstance()
REMOVED
the references to the FacesContext EL resolving in the implicit EL
resolver area
Please help us test this thoroughly as more CDI related changes are
coming down the pipeline.
Thanks for your help!
Manfred
On 10/7/14, 10:34 AM, arjan tijms wrote:
> Hi,
>
> On Tue, Oct 7, 2014 at 5:19 PM, manfred riem<manfred.riem_at_oracle.com> wrote:
>>> I wouldn't be surprised if there is code out there that assumes the
>>> instance returned by FacesContext.getCurrentInstance() is *NOT* a
>>> proxy. If so, that code will likely break. Do we care about that?
>>> Personally, yes, I do care about that. Does anyone else think this is a
>>> risk?
>> And that assumption won't change. The FacesContext.getCurrentInstance() call
>> still returns the same thing. The #{facesContext} expression returns the
>> proxy.
> Indeed, code that currently uses FacesContext.getCurrentInstance();
> will see no differences whatsoever, as it will return the same old
> regular instance that has always been returned.
>
> For those situations where a FacesContext is passed along that was
> originally obtained by resolving #{facesContext} or by injection via
> "@Inject FacesContext context;" there will thus be a proxy, but I
> wonder if code is really capable of seeing any real difference.
>
> Kind regards,
> Arjan Tijms
>