On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 2/7/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>
> On 2/7/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > Digester - ??
> >
> >
> > Recently had a 1.8 release to clean up memory leaks and a few other
> bugs.
> > For a 1.x release it seems like you could call it stable. But the
> > architectural approach (including its dependence on the six year old
> > BeanUtils architecture) could certainly use a remodel.
>
> Do you have a suggestion/idea on what you would replace BeanUtils with?
I'm biased by my own experience, of course :-), but any implementation of an
expression language has to solve the same set of problems that BeanUtils
solves, plus a whole lot more. Coupled with the fact that the JSP/JSF
expression language APIs are being split out into a separate spec so you
could have implementations of it that have nothing to do with the web tier,
if I were building Digester today I would likely think about mapping the
property setter type rules to EL evaluations.
I went "looking for el" today - had to first work out what spec
versions were related.
So Commons EL is used in Tomcat 5.x which is Servlet 2.4 / JSP 2.0.
The independant EL Craig's talking about relates to Servlet 2.5 / JSP
2.1 and will feature in Tomcat 6 (currently beta).
Unfortunately it seems that the Tomcat project has developed the
independant EL for Tomcat 6 "in house" as part of their project -
rather than building a new version of Commons EL here. This seems a
shame - both from a Commons EL PoV since its now a legacy/dormant
component and for the type of thing Craig is suggesting - using EL
independantly of a servlet environment.
I wonder if we could entice the Tomcat folks to do the development of
EL here rather than in their repo - if they haven't already got commit
access here (which I'm sure at least some have) - I'd be happy for
them to have it. Anyone else think this has merit or should we just
let EL lapse?
Niall
(Of course, because we're dealing with XML directly here, XPath expressions
might be another choice ... but they will be less familiar to Java
developers.)
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
