commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [digester] extension annottaion proposal
Date Sun, 04 Oct 2009 00:01:20 GMT
On Sat, Oct 3, 2009 at 4:32 PM, Simone Tripodi <> wrote:
> Hi all commons folks!!!
> I've been happily using the digester package since the 1.6 release, I
> found it very easy to use and absolutely one of the best way to parse
> quickly XML documents and mapping them to Java objects :)
> Even if using the XML rule declaration, or coding Digester rules, is
> absolutely very very easy, times ago I started implementing as a PoC
> [1], in my spare time, a facility tool able to create Digester
> instances automatically... taking inspiration by Google-Guice and
> JPA's annotations, I wonder: "why can't we generate the Digester's
> Rules through Java5 annotations?"

May be about time :-) Annotations are probably a good idea for a
number of digester usecases. The competing viewpoint has been that
turning the digester "configuration" into a distributed definition of
the rules can hinder readability (and thus, understandability,
maintainability etc.). Seems best to leave that choice to users.

> What I realized in my mind was the
> phrase "Basically, the Digester package lets you configure an XML ->
> Java object mapping module, which triggers certain actions called
> rules whenever a particular pattern of nested XML elements is
> recognized."
> So, my idea is: simply given an Annotated Class, we wanted to inspect
> it, and extract all the needed to generate the rules - in this way, we
> could save time writing the rules manually and reduce the errors while
> binding properties and methods'name, arguments etc, etc.
> and a special DigesterLoader is able to create Digester rules simply
> by analizing the ServletBean class:
> Digester digester = DigesterLoader.createDigester(ServletBean.class);
> And that's all!

Cool :-) And given that a slew of classes may need such inspection,
providing means to scan a package (or two) makes sense as well.

> While publishing this work on the Web (already licensed under the
> Apache 2.0 License) I wonder whether or not the
> Apache Community might be interested on this... would this be of
> interested to the community? is there anybody else out there
> in the community worked on something similar? I would more than happy to
> collaborate and find a way to merge the work into a bigger project eventually.

I can see this being useful. As you know, theres nothing along these
lines in SVN here. WRT collaboration and how things work around here,
please read this if you haven't already:

> I aim to achieve a mature version of the project quicker and better; and
> ultimately after submitting the proposal to the Commons Commettee as Digester
> extension we would like to  find ways grow the work in an official module of the
> distribution or a sub-project.

Makes sense, the digester project doesn't have sub-projects so first
impression is if it isn't too much code adding it straight to be
library may be an option. Otherwise, something like a multi-module
Maven2 build for digester may be another option. If you ever wanted to
consider that route of proposing the code for inclusion into Commons,
and if the larger Commons community showed interest and supported it,
the IP clearance process described here would need to be followed:

This is for any code proposed for inclusion in that has been developed
outside the ASF repository.

> Last, I would personally be really happy to contribute to the ASF in any way and
> maintain the above work if necessary.

Thanks for your interest and offer to contribute. Given that you
aren't a committer already AFAIK, this will be quite a slow process
and you will need to have a whole lot of patience :-) I may be able to
help, but my cycles are limited so you'll have to bear with an often
slow pace of progress. Ofcourse, if more folks are interested things
can always speed up with the involvement of other committers.


> Thanks in advance, best regards!!!
> Simone Tripodi
> [1]
> --

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message