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 ??
Please comment. Thanks much
Tim
David Jencks wrote:
I think we have a lot of work to do for annotation processing, and I
don't recall seeing any discussion of the steps involved. I haven't
read most of the specs involved so what I say is probably full of
errors, but this provides a great opportunity to correct me :-)
I think there are 2 kinds of annotations: some describe something about
the class that is exposed to the outside world, such as @WebService, and
some describe something supplied to the class from its environment, such
as @Resource. The @Resource type annotations result in something
getting bound in the components java:comp/env jndi context, and then
that thing getting assigned to the annotated field.
I believe all of these need to be translated to the xml in the spec
deployment descriptor and made available through jsr-77. This is a
pretty major change to jsr-77 since previously we were supposed to
provide the dd unchanged as a string.
I think that there is no further information needed for the "exposing"
annotations: once they are in the xml, we can just deploy from the xml
and we're done. However for the "resource injection" annotations, we
still need some code to get the object out of jndi and put it into the
field.
So, here's how I imagine this working:
Deploy time:
1. scan all the classes for annotations
2. process them into the xml descriptor
3. deploy from the modified xml descriptor, includiing constructing the
jndi tree (as done currently)
4. add objects to inject resources
Run time:
start up just like we do now
So, I don't think we have any of this code in geronimo. I suspect there
is a bunch of simliar code in other projects such as openejb, openjpa,
and cxf (at least) How much can we crib from elsewhere?
Comments desperately needed :-)
thanks
david jencks
--
Thanks,
Tim McConnell
