> > 
> > 
> > Hmmm, just looked at sun -  there's something called JAXB that apparently
> > compiles an xml schema into a custom parser that does 2 way translation
> > between xml and an object tree.  Since this is an impending standard it
> > will presumably be the way to go.. for castor as well.
> 
> I don't really like the idea of having to regenerate classes whenever
> the DTD/schema changes, but JAXB does look kind of cool.

If you look into the expert group for JAXP (JSR 031) you'll find Intalio
there. This is the company that's behind Castor and the entire
exolab.org.

Castor has 2 ways of providing you with marshalling/unmarshalling your
Java objects into/from XML

SourceGenerator:
        You just write an XML schema for you XML, run Castor's
        SourceGenerator, it builds a hierarchy of classes. Objects of
        these classes are used upon unmarshalling of an XML to build an object
        tree. You can specify a common superclass for all the generated
        classes, and package name.

more advanced choice

XML mapping
        You have your custom hierarchy of classes that you use to build
        object trees that you want eventually to marshal into/unmarshal
        from XML. You write a mapping.xml file which describes the
        mapping. Castor uses reflection API to marshal/unmarshal using a
        combination of your mapping.xml and default rules, if something is
        missing from your mapping description.


In either case, you never have to mess with XML parsing yourself, Castor
does the fancy footwork of setting all the fields and building the object
tree for you.

Here is my experience of using Castor. I've used SourceGenerator to create
class hierarchies to marshal/unmarshal application.xml, ejb-jar.xml and
jboss.xml

I use these to automatically generate/modify deployment descriptors. As
far as working, the system works well but I find using the class hierarchy
generated by SourceGenerator a bit cumbersome. The reason is, probably due
to poor XML design of these config files. Perhaps, I am wrong here.

Just my 2 cents:
ejb-jar.xml
- Information that is logically coupled (ejb description, method
permissions for this bean and method transaction settings) are located in
different entities. The default generated classes, obvously do not have
any idea of the logical coupling. When I need to gather all the
information about a bean, I have to traverse the objet tree looking for
objects which are related and putting them together with my own 'glue'
classes. Ideally I would want logically-related items to be glued together
during unmarshalling automatically. I'll probably have to look at custom
mapping through XML mapping, when I have a clearer picture of things.

For those interested, I can provide my XML Schemas of the standard config
files that I've been using to build my class hierarchies.

http://www.cs.nyu.edu/~akkerman/schemas.jar

(I had to recover jboss.xsd, so it may not be exactly correct, I'll
recheck it and might update it)

Anatoly.

> 
> Toby.
> 
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
> 



_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to