tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: JSP 2.1 Update
Date Thu, 02 Feb 2006 11:29:38 GMT
Jacob Hookom wrote:
> Hello All :-)
> I currently have the new EL-API integrated into the jasper runtime and 
> it's used under the covers of the deprecated jsp.el.* classes.  Ex, 
> ExpressionEvaluatorImpl within Jasper instead makes calls to a new 
> ExpressionFactoryImpl from the EL-API.
> Yet to do:
> 1) Incorporate the new EL-API into the jasper-compiler
> 2) Incorporate the taglib definitions for deferred syntax #{..}


> I'd also like to bring up a possible performance optimization for EL.  
> Right now, all EL evaluations produced by the jasper-compiler are 
> referenced by the String expression-- causing a re-parse on every 
> invocation within commons-el.  The optimization would be to have the 
> compiler actually retain reference to the parsed Node tree from 
> org.apache.el.  This would basically marry the EL implementation to the 
> compiler-- so I guess it's somewhat of a trade-off.

I know the old EL implementation included some kind of cache too. I 
never did any performance study of the EL, though.

> In looking at the current EL compilation within Jasper, I'd like to rip 
> a lot of it out.  Basically two code bases of the EL spec are being 
> maintained for parsing (one within the jasper compiler, and one from the 
> el-implementation).  As a carry-over from my last suggestion, do you 
> think it would be practical to just use the org.apache.el for expression 
> validation without maintaining a separate set of parsing logic within 
> jasper itself?

Sure, if it's possible to have only one EL implementation, it would be 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message