JSP 2.1 Update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

JSP 2.1 Update

Jacob Hookom
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: JSP 2.1 Update

Rémy Maucherat
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 #{..}

Ok.

> 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
great.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]