axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Have you guys looked at Avalon? ---->marshal unmarshal tool
Date Wed, 12 Sep 2001 17:25:37 GMT
Geoff Hendrey wrote:
> Giacomo, can you send me the tool for doing the (un)marshal from schema? I'd
> like to get a look.

I sent you the source code and most of the jars required to build it.  I appologize
for the overly large email (the largest part was the Cocoon jar).

There are almost no instructions, so the quick and dirty is that you
feed the utility a schema, and it generates a bunch of classes.  The concept
is simple.  It does support namespaces, and it has been used as a Q&D
(Quick & Dirty) SOAP message handler.

The goals for this is to modify it to be more in line with the JAXB
spec (i.e. the objects marshal/unmarshal themselves) which hides
alot of methods and variables that are needed for that process.
It also needs more support for the Schema standard.

Check the demos that come with it to get a better idea.

> -geoff
> -----Original Message-----
> From: Sam Ruby []
> Sent: Friday, September 07, 2001 2:11 PM
> To:
> Subject: Re: Have you guys looked at Avalon?
> Berin Loritsch wrote:
> >
> > As far as full Avalon integration, I will wait until we have more input
> from
> > others on the list.
> Don't wait too long...  others may not comment until they start to see the
> code.  ;-)
> > I would like to provide a couple hooks to allow Axis to
> > be embedded in Phoenix and used from Cocoon.
> +1
> > Giacomo sent me a tool that he
> > would like to be opened up that can assist with more complex schema to
> object
> > mappings.  Basically, it provides a (un)marshalling service for objects
> that
> > it creates.  It creates the business objects from an existing Schema.
> The
> > tool is based on Avalon, and is pretty decent.  It might be of use in
> this
> > project.
> As I said, we have somebody looking into this too.  If there is some way
> that we can collaborate, so much the better.
> > This does not interfere with how WebSphere/JRun handle their own
> configuration
> > schemes.  It is internal to how Axis would do it (if Avalon is adopted).
> We may have differnent ideas about what "does not interfere with" means.
> WebSphere will likely want the configuration data expressed in XMI (see
>, and integrated with the WebSphere
> Admin GUI.
> Having classes implement
> org.apache.avalon.framework.configuration.Configurable should not interfere
> with this.  Specifying a DTD or proscribing a mechanism by which such data
> is loaded would.
> - Sam Ruby

View raw message