Hi Ed,
On 10/7/14, 9:27 AM, Edward Burns wrote:
>>>>>> On Tue, 7 Oct 2014 00:50:23 +0200, arjan tijms<arjan.tijms_at_gmail.com> said:
> [Arjan's excellent summary deleted].
>
> AT> CDI will now insert that instance into the scope, proxy the instance,
> AT> and return it to its own EL resolver, which will return it to the EL
> AT> implementation, which will return it to whomever did a getValue() or
> AT> equivalent call in the first place.
>
> 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.
>>>>>> On Mon, 06 Oct 2014 16:26:55 -0500, manfred riem<manfred.riem_at_oracle.com> said:
> MR> Hi Leonardo,
> MR> If we let CDI handle the EL resolving of #{facesContext} it does not
> MR> imply in any form or shape that the JSF runtime is not in control of
> MR> creating the FacesContext. All it means is that when you have a
> MR> #{facesContext} EL expression it will use the CDI FacesContextProducer
> MR> to get the FacesContext.
>
> What does your proposal mean for the return from
> FacesContext.getCurrentInstance()? Will that still be the same, or will
> it be the proxy?
See above.
>>>>>> On Mon, 6 Oct 2014 23:52:02 +0200, arjan tijms<arjan.tijms_at_gmail.com> said:
> AT> The CDI spec does not have to know anything about FacesContext, since
> AT> it's the JSF dynamic producer that's in control. CDI only provides the
> AT> mechanism so that with a minimum amount of code the same instance can
> AT> be made available for both injection and usage in EL. The instance is
> AT> created by JSF using the existing FacesContext.getCurrentInstance()
> AT> call, so nothing changes there.
>
> Ah, so it will be the same instance as in prior JSF releases?
See above.
> AT> Another concern could be the existence of
> AT> FacesContext.setCurrentInstance(FacesContext instance).
>
> Yes, this is a valid concern, and we do indeed call that, and I'm sure
> folks outside of JSF call it. Again, do we care about breaking them?
We should be able to support this use case with some extra work on the
side of the FacesContextProducer. And yes we would have to make sure we
cover it with tests.
Regards,
Manfred