[jsr-314-open] [NEW - MR] Add ExpressionFactory to "11.4.6 Delegating Implementation Support"
Pete Muir
pmuir at redhat.com
Wed Aug 19 09:43:10 EDT 2009
On 18 Aug 2009, at 21:28, Ed Burns wrote:
>>>>>> On Tue, 18 Aug 2009 13:16:06 +0100, Pete Muir
>>>>>> <pmuir at redhat.com> said:
>
>
> PM> I'm not sure why this requires any changes to Unified EL, the
> change
> PM> is needed in JSF (see changes I suggested).
>
> Perhaps I misunderstood your feature request, then. Let me restate it
> in my own words and you can tell me if I understand you.
>
> You want to make it so the ExpressionFactory instance returned from
> Application.getExpressionFactory() is subject to the decoration
> construction pattern that we use for all the rest of our decoratable
> artifacts. Is that correct?
>
> The problem is that the JSF spec says the application must simply call
>
> JspFactory
> .getDefaultFactory
> ().getJspApplicationContext(servletContext).getExpressionFactory();
Aha, I hadn't realized this. In this case, simply wrapping the call
(no change to JSF spec) is the best approach IMO.
> We don't maintain a reference to the instance that is returned.
> Even if
> we started doing so, and performed the wrapping as an spec requirement
> of the javax.faces.application.Application implementation, you'd miss
> out on anyone who is creating expressions with the ExpressionFactory
> that you get from any other way than the Application instance.
Yes, I'm also talking to Kin-man. Unfortunately this looks like a big
change to the way EL works, so I think this may have to be a non-
portable SPI that CDI implementations expose for now.
> In other words, I assert that to satisfy your request, we have change
> the contract of how the canonical ExpressionFactory instance is
> created,
> which is currently the responsibility of the EL implementation.
Agreed, it looks like we have to require something in EL itself.
Thanks for the clarifications :-)
More information about the jsr-314-open-mirror
mailing list