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
