commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [digester] extension annottaion proposal
Date Sun, 04 Oct 2009 09:47:45 GMT
Hi Rahul,
very nice to meet you and thanks for your kind reply :)

On Sun, Oct 4, 2009 at 2:01 AM, Rahul Akolkar <> wrote:
> 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?"
> <snip/>
> 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.

Yes I totally agree, I didn't explicate very well, but my intention is
providing a new package
that could be used in combination with the existing ones and not
totally replace old methodologies :P
I already met a case where annotations weren't enough so I had to add,
by programmatic way, missing rules.

>> 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.
> <snip-provided-example/>
>> 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!
> <snap/>
> 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.
> <snip/>
> 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:

Thanks to remind me, I'll take a deeper look to have more clear these

>> 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.
> <snap/>
> 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:

Thanks. That's foundamental, I'll read it more than once.

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

Well, my original idea was providing a runtime annotation interpreter
and a compiler,
so I though about subprojects, but at this stage - I still haven't
thought about how to realize
the compiler :P - I'm confident that by adding just a new subpackage
in the existing project is enough.

>> Last, I would personally be really happy to contribute to the ASF in any way and
>> maintain the above work if necessary.
> <snip/>
> 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.

No I'm not an Apache committer, I already contributed to Apache Cocoon3
submitting patches so I'm already a little familiar with how the process works,
the Cocoon3 guys are very nice people and helped me to understand :)

> -Rahul

Thank you once again, I really hope to continue in receiving feedbacks!!!
Best Regards

Simone Tripodi

>> [1]
>> --
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


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

View raw message