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.
>
> 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.
>
I may be misreading this one, but why move into the DBCP bundle? This
seems like it would be a good example of what the sandbox is available
for, two similar implementations for a similar need. Any comments?
I am still going back through the proposal emails, hopefully I can
sit down and read them through shortly. This would get a definite +1,
especially with the inclusion of the Digester stuff.
David
> - 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
>
