[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