geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: openejb-jar-2.2.xsd out-of-date?
Date Thu, 12 May 2011 04:10:35 GMT

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

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

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

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.


View raw message