On May 5, 2011, at 12:44 AM, han hongfang wrote: > The openejb-jar-2.2.xsd comes from latest geronimo server v3.0-snapshot build > under schema folder. To me, I think this xsd file is invalid since for > example[...]
Right, as I mention the JAXB tree and schema are not well maintained. Sometimes the JAXB tree is updated the schema is not or vice versa. > Another question is, in geronimo v3.0-snapshot, which schema should the > deployment plan openejb-jar.xml comply to? openejb-jar-{versionA}.xsd or > geronimo-openejb-{versionB}.xsd, or even both are OK? and what the value of > {versionA} and {versionB}? The old Geronimo specific openejb-jar v2 is read in, if found, and split into the new geronimo-openejb.xml file (geronimo specific) and the new openejb-jar.xml file (not geronimo specific). As noted the link it was done mostly for backwards compatibility. The TCK and all our docs and examples still use the "old" openejb-jar.xml file and not the new geronimo-openejb.xml+openejb-jar.xml file. And actually, some of the CMP parts of the old openejb-jar.xml are translated into JPA mapping files. In Geronimo 1.0 we used TranQL and now we use JPA to deliver legacy CMP info. So really that old openejb-jar.xml file gets split into potentially 3 files: geronimo-openejb.xml, openejb-jar.xml and jpa mapping.xml for for any CMP beans. As for which "wins", we first try to read in the openejb-jar.xml as the new version. If that fails we try again using the old version and then will do the conversion and OpenEJB, Geronimo and OpenJPA will each get their parts. > I'm considering to reuse these JAXB objects in Geronimo server adapter v3.0. > Can you point me to the exact xsd file for this JAXB objects? I did a quick > check, and can not find some classes in openejb-jar-2.2.xsd and > geronimo-openejb-2.0.xsd, which come from latest geronimo v3.0-snapshot > build, e.g., AbstractClusteringType. Some of the parts of the related Geronimo schemas are not read into the tree as strong types. Anything in the 'clustering', 'abstractNamingEntry', 'service' and 'security' elements are packed into generic JAXBElement types. All this stuff was generated by the JAXB compiler which wasn't able to handle some of the more clever things David J. did with the Geronimo schemas. The result was those abstract classes like AbstractClusteringType that have no concrete implementations. It's technically accurate representation of the schema, but functionally useless. All the generic information is lost at runtime so "JAXBElement<? extends AbstractClusteringType>" is really just "JAXBElement" and the AbstractClusteringType never factors in. The entire JAXB tree (JAXBElement data and all) is/was ultimately handed over to XMLBeans which does/did the real work. There wasn't any interest in using JAXB in Geronimo itself then so most of the real code was done by Geronimo with XMLBeans copies of the descriptor data. So the JAXB tree only needed to be good enough to do the conversion and get the xml where it needed to go. Worked well enough for 4-5 years, but now we have a new major version and we could chose to do things all differently if we want. > Meanwhile, I plan to put the JAXB objects of geronimo-openejb-{version}.xsd > and openejb-jar-{version}.xsd into separate package. I suspect the goal is to write some tooling and in that front the current JAXB tree might not be what we want to be focusing on going forward. Certainly, the fact that much of the tree is just loosely typed JAXBElement objects and not concrete classes, it won't really do the trick as-is now. We'd have to invest time in fixing it up, at least a little. I think we need to ask ourselves if this is really the setup we want going forward. Was hoping to hear from David J at least. Let me take another shot in a follow up email. -David