commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [all] Status of components
Date Thu, 08 Feb 2007 17:01:53 GMT
On 2/8/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
>
> On 2/7/07, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 2/7/07, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> > >
> > > On 2/7/07, Craig McClanahan <craigmcc@apache.org> 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?


I think it would indeed be useful ... but as usual in life there will be
complications.

The EL spec itself defines basic APIs like ELContext and ELResolver, plus
some factory and configuration methods to glue them together and get
instances.  On top of that, JSF and JSP provide a whole pile of resolvers
that provide the default functionality you need in that environment (for
example, the gadget that makes managed bean creation happen) on top of it.
>From the viewpoint of the Tomcat folks, this might indeed be reasonable to
keep in their own repository ... while perhaps moving the generic part here.

In addition to Tomcat, I know that Facelets and MyFaces both have some stuff
in this area, and Geronimo will eventually have to do something (although
they'll probably start by inheriting from whatever JSF and JSP
implementations they choose).

Come to think of it, Shale's test framework has started implementing mocks
for these classes so you can unit test JSF 1.2 based apps.  But you have to
build so much of the infrastructure to make this actually work that it's
pretty close to implementing the generic part of the EL APIs.  It'd be
interesting to think about moving that part over so it can be shared.

Niall


Craig


> (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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message