On Mon, 2 Apr 2001, Waldhoff, Rodney wrote:
> > Would it be worthwhile talking about collaborating on this, or do you
> think
> > there is reason to have both [JOCL and Digester]? It appears to me we
> could
> > define a set of standard Digester rules that correspond to the JOCL
> operations,
>
> JOCL is just yet another XML configuration utility. I'd be more than happy
> to collaborate with you to integrate the JOCL functionality into Digester.
> In fact, I was a little hesitant to submit JOCL at all thinking that its
> functionality is superceded by or easily integrated with another XML
> configuration utility like Digester.
>
> > but I'm definitely not as familiar with JOCL as you are.
>
> And vice versa for Digester. This may help:
>
> The primary purpose of JOCL is to provide human-editable representation of a
> Java object (or a list of Java objects) to be instantiated. For example,
> the JOCL fragment:
>
> <object class="java.util.Date">
> <int value="1"/>
> <int value="2"/>
> <int value="3"/>
> </object>
>
> will invoke "new java.util.Date(1,2,3)" and add the result to a simple list.
>
OK, calling a constructor with parameters is not something built in to the
standard rules for Digester at the moment. It is currently focused on
calling the zero-args constructor, and then "configuring" the object based
on calling property setters.
With the standard Digester ObjectCreateRule, you could set up rules like
this:
digester.addObjectCreate("object", "java.util.Date", "className");
digester.addSetProperties("object");
and then create/populate the object like this:
<object className="java.util.Date"
year="101" month="04" date="03" hour="15" minutes="15"/>
and so on. It would not be hard to add a different kind of object create
rule that would accumulate constructor argument values from nested
elements in the same way that method parameters can be accumulated:
digester.addNewKindOfCreate("object", "java.util.Date", "className");
digester.addConstructorParam("object/year", 0);
digester.addConstructorParam("object/month", 1);
digester.addConstructorParam("object/date", 2);
in order to process something like:
<object className="java.util.date">
<year>101</year>
<month>04</month>
<date>03</date>
</object>
or other variations that grab the argument values from attributes instead
of elements.
> I find this useful because I commonly create small frameworks (like the
> DBCP) that are really aggregations of different objects. Writing a custom
> configuration file format for that would be a hassle, especially since
> clients can create there own classes that integrate with the framework.
> Since JOCL just uses reflection and a generic XML representation of
> constructors, new classes are automatically supported by the JOCL syntax.
>
Digester supports composing trees of objects through the following design
patterns:
* Normally, created objects are pushed on to the stack
at the top of the element, and popped off at the end
* Because of this, nested elements are naturally available
on the top of the stack
* Digester provides standard rules that call a method on the
top-of-stack object, passing the next-to-top object as a
parameter (and vice versa) that are useful in establishing
parent-child relationships.
Struts uses this to process the struts-config.xml file, and builds trees
of resulting objects -- from a mixture of classes from any available
source -- with property setting and parent-child relationships all built
using Java reflection. Tomcat uses a similar approach (using a module
called XmlMapper on which the design of Digester was based) to read
web.xml files as well as the server.xml configuration file for the server
itself.
> Hence the main feature of JOCL, as I see it, is that any class can be
> represented/configured without adding any new code. The same may be true of
> Digester, that's not entirely clear to me. Certainly there is some overlap
> with the Merlin/JDK1.4 XML serialization (assuming I can create the XML ser
> files by hand), and maybe even with SOAP.
>
Making sure it is easy to deal with SOAP messages is high on my priority
list for Digester.
> I have been thinking about some extensions to JOCL that would (a) allow the
> invocation of methods as well as constructors and (b) support a map of
> object references, rather than a list, but certainly the Digester/BeanUtil
> syntax seems convenient.
>
Digester can do (a) pretty well. Because of that, you can actually build
arbitrary graphs of object relationships -- which is what I *think* I
understand that you want with (b).
> How about this: I'll move the JOCL classes in the DBCP bundle for now, drop
> the JOCL proposal, and poke around with Digester as the XML configuration
> language for DBCP. I haven't looked at Digester too hard, but I'm sure we
> can make it do what I want if it doesn't already. If you want, feel free to
> put me down as an initial committer in the Digester proposal when you submit
> it.
>
Sounds like a good short-term plan. I will definitely sign you up when
Digester is ready to be proposed!
> - Rod
>
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, March 31, 2001 2:54 PM
> To: '[EMAIL PROTECTED]'
> Subject: Re: RFC: JOCL Package
>
>
>
>
> On Wed, 28 Mar 2001, Waldhoff, Rodney wrote:
>
> > Here's one of the proposals I was talking about in my earlier email. I
> > thought we could kick it around a little bit before submitting a real
> > proposal.
> >
> > The Java Object Construction Language (JOCL) provides an XML syntax for
> > describing one or more objects to be instantiated. It's most useful when
> > trying to persistently configure objects that rely on a lot of
> aggregation.
> > This is the proposal I'm least sure of. I find JOCL pretty useful (we use
> it
> > for a number of modules, some of which I'd like to contribute to commons),
> > and I needed it or something like it for the DBCP stuff, so I dropped it
> in
> > as a separate package. I think that this functionality could pretty
> easily
> > be built into another XML-based configuration language (like Digester for
> > example) but it serves my immediate needs.
> >
>
> I was planning to propose Digester (once I got the Commons version of
> BeanUtils far enough along, because Digester depends on it). Would it be
> worthwhile talking about collaborating on this, or do you think there is
> reason to have both? It appears to me we could define a set of standard
> Digester rules that correspond to the JOCL operations, but I'm definitely
> not as familiar with JOCL as you are.
>
> > For the time being, the package can be found in the bundle at
> > http://www.webappcabaret.com/rwald/commons/. I'll move it into the
> sandbox
> > when I get access.
> >
> > Comments?
> >
> > - R.
> >
>
> Craig
>
