tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Hookom <ja...@hookom.net>
Subject JSP 2.1 Update
Date Thu, 02 Feb 2006 06:56:32 GMT
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.

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?

I guess coming from the Facelets project, I just delegated pre-parsing 
to the javax.el.ExpressionFactory instead of re-implementing the EL-spec 
within the compiler.

-- 
Jacob Hookom  -  Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message