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