On 2/9/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 2/8/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 2/8/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> >
> > 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?
>
>
> 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.
I posted a message to the Tomcat Dev list[1] about this - so have to
see what (if any) interest there is from their side.
[1] http://tinyurl.com/2hozrg
Just as a follow up to this - Tomcat is now publishing the EL jars in
the main maven repo - from my PoV the main thing is having access to
an ASF compatible EL implementation and the location isn't that
relevant.
Niall
> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
