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
