On 2001.11.27 15:38:07 -0500 Anatoly Akkerman wrote: > > > what if we use xslt to transform the deploymentdescriptors to > jdk1.4's > > > longterm persistence format and let the task of parsing the xml and > > > instantiating the metadata beans to the java.beans.XMLDecoder .. this > > > > would at least enhance maintainability. > > > > > > Very interesting idea. I was playing with using jaxb for xml to object > > conversion, although there may be license issues with it. Offhand, it > > looks to me as if using the jdk 1.4 persistence format (I just read > about > > it for 5 min or so) would involve some pretty heavy-duty xml > > transformations and require jdk 1.4. Jaxb appears (in very preliminary > > experiments) to be able to generate classes from the ejb 2 dtd and > > jbosscmp-jdbc dtd. > > > > sooo.. > > > > --jaxb requires using specially generated base classes but requires > minimal > > xml transformation. License may make it unavailable (???? anyone else > have > > an opinion about this???) > > Probably the simplest thing to glue these things would be using Castor > with custom mapping and/or autogenerated classes. (JAXB seems to be an > effort to standardize Castor-like technologies from various players in > the > field. From what I remember Exolab (or Intalio, or whatever their current > name is) was a member of this JSR. > > Castor has a mode where you write your custom class hierarchy that would > be used to represent an XML in object tree form. Then you write a special > XML file which describes how these classes are mapped into XML entities > and attributes. Then you can simple use a Marshaller or Unmarshaller to > store/restore an object tree to/from XML. > > The other mode that Castor provides, is auto-generation of classes that > would represent any valid instance of an XML file that conforms to a > given > XML Schema from which the classes are generated. This is, in a way, a way > for the lazy guys to get around learning SAX or DOM (exactly what I > did). And this is what JAXB seems to promise at the moment. Though, JAXB > only works with dtds at the moment, while Castor can already deal with > XML > Schemas which are far more expressive than DTDs. > > In my current project I am using auto-generated classes for J2EE and > JBoss > descriptors (J2EE 1.1 and JBoss 2.2 or something like that). As a head > start I can provide XML Schemas which I've used to produce the class > hierarchies with Castor. For some custom XML descriptors that I am using > to store my project's metadata, I have written custom classes and used > mapping technique of Castor. I can share my experiences with those as > well. It is a solid technology, though, I am glad I did not have to mess > with SAX or DOM. > > This is how you would glue several files together. Say you have > ejb-jar.xml > jboss.xml > jaws.xml > > You unmarshal all 3 files and get 3 objects, say, instances of > jboss.xml.j2ee.EjbJar > jboss.xml.jbossconf.Jboss > jboss.xml.jbossconf.Jaws > > Then you create a new instance of a class (which is also marshallable by > Castor), say jboss.xml.SuperJBoss > and add the above 3 objects into that newly created objects with > appropriate set() methods. > > then marshal SuperJBoss into a file, say super-jboss.xml > > Vice versa it is similar: > > unmarshal SuperJBoss from an XML file. > Obtain subcomponents with appropriate getters, > store them individually in each one's XML file. > > Voila. (Well, sort of) > > Anatoly.
Can Castor merge nested attributes from all the files into one object? For instance, there are elements under ejb-jar/enterprise-beans/entity and jboss-cmp/enterprise-beans/entity that should all end up in result-dd/enterprise-beans/entity. Just having copies of all 3 docs in the super-jboss is probably easier with including an xml entity;-) david jencks _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
