Hi David, sorry if I wasn't sufficiently clear. I not suggesting that we redo anything that's
already been done for annotations in the other projects (e.g., openejb, openjpa, cfx, axis, etc..).
I'm really just suggesting that there is some amount of work remaining in Geronimo related to
deployment and annotations (e.g., JSR-88, JSR-77, JSR-250, etc.) and since I've volunteered to be
responsible for JSR-88, I thought it might be more efficient to have as many of these changes as
possible done as part of the JSR-88 implementation. I "believe" this is a valid assumption for
JSR-77. I'm not as certain about any of the other JSR's though.
Thanks
David Blevins wrote:
On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote:
Hi David, thanks for kicking off this discussion and I agree with most
of your steps
below. However, since it seems that "annotations" are now pervasive in
many of the JSR
specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably
even more that I
personally haven't uncovered) it seems like a concise set of
responsibilities for all these
annotation-specific JSRs might mitigate some confusion
and hopefully prevent overlap and/or conflicts (i.e., who is going to
do what).
So for example, I'm responsible for the Geronimo JEE5 Deployment JSR
(88) and I'm making these three
assumptions below:
1 -- The current Geronimo JSR-88 implementation will be enhanced (by
me) to provide a
"metadata-complete" XML deployment descriptor, which is essentially
what you've described
below in steps 1-3.
2 -- The work associated with assumption #1 should encompass as many
of the impacted JSRs as
possible on the Geronimo side from a deployment perspective to
minimize the number of
folks making similar changes to the Geronimo builders/deployers. Thus,
these JSRs should be
encompassed by the JSR-88 implementation for Geronimo:
-- JSR 77 (JEE5 management--this JSR in particular has already
been mentioned as a
candidate by Paul and Chris and I agree with them)
-- JSR 88 (Deployment)
-- JSR 175 (Java annotations)
-- JSR 181 (Web Services metadata)
-- JSR 250 (Common annotations)
3 -- Your step number 4 below (add objects to inject resources) feels
like a duplicate of
your step 3 (deploy from the modified xml descriptor...) but again
will/should be
implemented under the auspices of JSR-88.
So, if that seems reasonable then I would still have a couple questions:
1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a
separate and distinct
deployment implementation for annotations in OpenEJB ?? I'm guessing
yes based on the
OPENEJB-216 JIRA and all its subtasks but just would again like some
validation so as to
better understand the implications if any from a Geronimo
responsibility perspective.
2 -- Are there any other JSRs impacted by annotations for JEE5
compliance ??
Well, that's certainly an interesting idea. There are 149 annotations
in all of Java EE 5 [1] and only 10 of them are generic JSR 250
annotations -- and most specs don't use those. Are you sure
consolidating all of them into one task is a good idea? You'd be
looking at months of work just to catch up to where most projects
already are.
If this is truly just about getting meta-data complete descriptors,
there's really no work for ejbs anyway as there'll be a
metadata-complete ejb-jar.xml in the GBeans we produce from deployment
which is the way the current integration satisfies the JSR-88 requirement.
Thoughts?
-David
[1] Made a list for you
http://cwiki.apache.org/GMOxDEV/java-ee-5-annotations.html
--
Thanks,
Tim McConnell
