geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@gmail.com>
Subject Geronimo 3.0 and descriptors (was: Re: openejb-jar-2.2.xsd out-of-date?)
Date Thu, 12 May 2011 04:37:54 GMT
Soo....  The discussion on the openejb-jar.xml confusion has brought up some relevant topics
(see the previous email for backstory).  Such as we probably need to decide what we might
want to do with our descriptors going forward.

At least in terms of David Jencks' branch changes, gbeans and are dead and there's no more
dependency information in the descriptors anymore.  David can probably fill in some details
as well as maybe comment on the likely hood of us releasing a 3.0 final with that code, but...

Certainly in terms of the EJB related descriptors we already have a ton of legacy and it looks
like we're getting more.  Specifically:

  1. osgi/gbean changes (the branch changes). No more dependency information.  Not sure the
impact on naming and gbean specific queries.

  2. "clustering" elements.  No one to my knowledge has ever used or even tried to use the
WADI clustering stuff.  Do we want to keep carrying it forward?

  3.  CMP data.  CMP is dead and we could probably get along fine just making the 1, 2 or
0 users out there use the jpa mapping file directly.

  4.  The 'openejb-jar' element of the new geronimo-openejb.xml file.  From a Geronimo perspective,
the only thing useful in it that is not already in the geronimo-openejb.xml jar file is the
ability to specify which container you want your bean deployed in -- assuming you don't want
the default.  That's a rare case, but certainly would be easy to add to the geronimo-openejb.xml
file.

If we're going to change all the geronimo descriptors incompatibly, then maybe we want to
kill the openejb-jar.xml file in the process, switch everyone over to a new-new geronimo-openejb-3.0.xsd
(not yet written) and make the related JAXB in Geronimo land.

If we aren't changing things incompatibly, then maybe we just leave things alone and try to
make tiny changes where needed.


Any thoughts?


-David


Mime
View raw message