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