> > 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. > > --jdk 1.4 persistence can use regular classes but requires a lot of xsl, > and jdb 1.4. > > Any one have experience with both or at least an opinion? > > Thanks > david jencks > > > > > > > > > > Good idea or am I nuts? > > > > > > > .. definately I am ;-) > > > > Holger > > > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
