I still believe that we should generate code from XML Schema files, either using JAXB or XMLBeans. The generated code would take care of marshalling/unmarshallign/validation/XML-Java mapping/etc, in a very elegant an easy way.
Since metadata is a common problema for all of JBoss codebase, my proposal was oriented in that direction. I was not necessarily thinking about your scenario alone.
Ricardo Argüello
Alexey Loubyansky wrote:
As for me, this is the worst scenario. - generate interfaces for three schemas, - implement those interfaces, - merge them into another object model.
Why would we want to change the existing code then?
I could provide an implementation that will populate just one object model w/o generating additional interfaces by improving the 'IOC' metadata factory with 'look-ahead' feature.
In fact, my approach would solve my current problems. The binding tools that looked at seem to be too heavy weight for me. But metadata is a common problem. Therefore, I wanted to know about other requirements. But noone wrote any till the moment. So, if your proposition is for my problems then negative.
Ricardo Argüello wrote:
We could add vendor specific elements (i.e. the ones found in jbosscmp-jdbc.xml) using namespaces.
I'll have to investigate if we could generate a different object model for each namespace.
But, altough it might be possible to do this, I wouldn't recommend it.
I would generate a different object model for each deployment descriptor: One object model for each Sun's standard XML Schema and one object model for each JBoss' deployment descriptor.
Maybe then we could write another object model to integrate both object models:
<made_up_code>
// This object was generated from j2ee-1.4.xsd: EjbJar ejbJar = EjbJarFactory.create(standarDDFile); String name = ejbJar.getEjbName();
// This object was generated from jboss-j2ee-1.4.xsd: JBossEjbJar jbossJar = JBossEjbJarFactory.create(jbossDDFile);
// We could have a single object to integrate both object models: EjbMetadata metadata = new EjbMetadata();
metadata.setStandarDeploymentDescriptor(ejbJar); metadata.setJBossDeploymentDescriptor(jbossJar);
// We could then work with only one object model: String name = metadata.getStandardDeploymentDescriptor().getName();
String jbossSpecificProperty = metadata.getJBossDeploymentDescriptor().getJBossSpecificProperty();
</made_up_code>
In conclusion:
1) We would generate the first object model using JAXB or XMLBeans, from Sun's XML Schema files.
2) We need to write XML Schemas for each JBoss vendor deployment descriptor.
3) We would generate the sencond object model from JBoss' XML Schema files.
4) We *could* integrate both object models coding another object model on top (no generation here). Then we could use this object model to access standard properties or JBoss' properties.
What do you think?
Ricardo Argüello
Alexey Loubyansky wrote:
Will we be able to have, say, entity related data from ejb-jar.xml, jboss.xml and jbosscmp-jdbc.xml in the same class? Or will we need three classes?
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
