You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/12/12 18:46:49 UTC
Annotation processing
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
Re: Annotation processing
Posted by Tim McConnell <ti...@gmail.com>.
Hi Sachin, I like your proposal for using annotations for our Geronimo-specific deployment plans. If
annotations do ultimately fulfill their intended purpose over time they could potentially simplify
the work for our end users in dealing/creating Geronimo-specific deployment plans.
Thanks.
Tim
Sachin Patel wrote:
> To broaded the topic, and I asked this earlier and didn't get any
> responses, but do we foresee needing annotations for any of our geronimo
> plans?
>
> On Dec 12, 2006, at 12:46 PM, 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
>>
>
>
> -sachin
>
>
--
Thanks,
Tim McConnell
Re: Annotation processing
Posted by Sachin Patel <sp...@gmail.com>.
To broaded the topic, and I asked this earlier and didn't get any
responses, but do we foresee needing annotations for any of our
geronimo plans?
On Dec 12, 2006, at 12:46 PM, 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
>
-sachin
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
On Jan 4, 2007, at 3:13 PM, Tim McConnell wrote:
> Now that's very interesting, I've been using the "Annotation Type
> Hierarchy" from http://java.sun.com/javaee/5/docs/api/overview-
> tree.html but your list appears to be more accurate.....
Seems like they're missing these two:
javax.xml.ws.addressing.Action
javax.xml.ws.addressing.FaultAction
Strange....
-David
>
> David Blevins wrote:
>> On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote:
>>> Hi David, your definitive list of JEE5 annotations is wonderful--
>>> I've been looking all over the
>>> place trying to locate the authoritative source. Where/how did
>>> you find them ??
>>>
>> Grepped all the spec jars and compared that against the TCK for
>> accuracy and to fill in any missing.
>> -David
>>>
>>> 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
>>>
>
> --
> Thanks,
> Tim McConnell
>
Re: Annotation processing
Posted by Tim McConnell <ti...@gmail.com>.
Now that's very interesting, I've been using the "Annotation Type Hierarchy" from
http://java.sun.com/javaee/5/docs/api/overview-tree.html but your list appears to be more accurate.....
David Blevins wrote:
>
> On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote:
>
>> Hi David, your definitive list of JEE5 annotations is wonderful--I've
>> been looking all over the
>> place trying to locate the authoritative source. Where/how did you
>> find them ??
>>
>
> Grepped all the spec jars and compared that against the TCK for accuracy
> and to fill in any missing.
>
> -David
>
>>
>> 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
>>
>
>
--
Thanks,
Tim McConnell
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote:
> Hi David, your definitive list of JEE5 annotations is wonderful--
> I've been looking all over the
> place trying to locate the authoritative source. Where/how did you
> find them ??
>
Grepped all the spec jars and compared that against the TCK for
accuracy and to fill in any missing.
-David
>
> 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
>
Re: Annotation processing
Posted by Tim McConnell <ti...@gmail.com>.
Hi David, your definitive list of JEE5 annotations is wonderful--I've been looking all over the
place trying to locate the authoritative source. Where/how did you find them ??
Tim
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
Re: Annotation processing
Posted by Tim McConnell <ti...@gmail.com>.
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
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
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
Re: Annotation processing
Posted by Tim McConnell <ti...@gmail.com>.
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
Re: Annotation processing
Posted by Tim McConnell <ti...@gmail.com>.
Hi David, what is this ASM acronym that you refer to below ??
David Blevins wrote:
>
> On Dec 13, 2006, at 1:53 AM, Greg Wilkins wrote:
>
>> David Blevins wrote:
>>>
>>> I took a quick look at Jetty and Tomcat source. Tomcat has some
>>> complete looking code for injection via JNDI, except it seems it only
>>> supports using annotations as the source of injection data, nothing for
>>> xml as the source.
>>>
>>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java?view=markup
>>>
>>>
>>>
>>> Jetty doesn't seem to have anything in this area. I looked for any
>>> references to javax.annotation and didn't find any. Greg, any thoughts
>>> on what your plans are in this area?
>>
>> Jan,
>>
>> any thoughts on what your plans are in this area?
>>
>> ...
>>
>> We do plan to support this, but it is rather painful and
>> intrusive to do. The injecting the resources is not the problem
>> it is finding them that is an issue. It appears that we must
>> get more involved in the classloading to find which classes should
>> be scanned for annotations. The code I have seen for this has
>> hacky special cases of jar not to scan etc etc.
>
> I made xbean-finder's ClassFinder for exactly this purpose. It uses ASM
> to introspect the classes for annotations as opposed to reflection
> avoiding the security issues that would associated with loading each and
> every class looking for annotations.
>
> http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/finder/ClassFinderTest.java
>
>
> Here's a good thread to give a quick read:
> http://mail-archives.apache.org/mod_mbox/geronimo-xbean-dev/200610.mbox/%3c6C2C4FB8-25E4-4B94-923F-33C778664784@visi.com%3e
>
>
> With it you can search:
>
> 1. A classloader, excluding any parent classloader if you wish
> 2. A set of URLs (var args... so one to many)
> 3. A set of Classes (also var args, so one or many)
>
>> So what we hope to provide is a mechanism to inject
>> (this should be done shortly) and a pluggable mechanism
>> for discovery of annotations. We will have our own simple
>> implementation, but ideally the integration with geronimo would share
>> the scanning that would be occurring for EJB3 etc. etc.
>
> For the injection, we use xbean-reflect, which Dain created and I've
> hacked on a bit to do field and private injection.
>
> Here's an example of how we use it to do JNDI-based injection (sans
> exception handling for brevity):
>
> ObjectRecipe objectRecipe = new ObjectRecipe(beanClass);
> objectRecipe.allow(Option.FIELD_INJECTION);
> objectRecipe.allow(Option.PRIVATE_PROPERTIES);
> objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);
>
> javax.naming.Context ctx = deploymentInfo.getJndiEnc();
> for (Injection injection : deploymentInfo.getInjections()) {
> String jndiName = injection.getJndiName();
> Object object = ctx.lookup("java:comp/env/" + jndiName);
> objectRecipe.setProperty(injection.getName(), new
> StaticRecipe(object));
> }
>
> objectRecipe.setProperty("sessionContext", new
> StaticRecipe(createSessionContext()));
>
> bean = objectRecipe.create(beanClass.getClassLoader());
>
>
> Note that the objectRecipe also has methods like setFieldProperty and
> setMethodProperty that allow you be more specific on where the data
> should go (field vs setter). The default when using the plain
> setProperty when Option.FIELD_INJECTION is enabled is to first look for
> a setter then to look for a field.
>
> -David
>
>
--
Thanks,
Tim McConnell
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
On Dec 13, 2006, at 1:53 AM, Greg Wilkins wrote:
> David Blevins wrote:
>>
>> I took a quick look at Jetty and Tomcat source. Tomcat has some
>> complete looking code for injection via JNDI, except it seems it only
>> supports using annotations as the source of injection data,
>> nothing for
>> xml as the source.
>>
>> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/
>> catalina/util/DefaultAnnotationProcessor.java?view=markup
>>
>>
>> Jetty doesn't seem to have anything in this area. I looked for any
>> references to javax.annotation and didn't find any. Greg, any
>> thoughts
>> on what your plans are in this area?
>
> Jan,
>
> any thoughts on what your plans are in this area?
>
> ...
>
> We do plan to support this, but it is rather painful and
> intrusive to do. The injecting the resources is not the problem
> it is finding them that is an issue. It appears that we must
> get more involved in the classloading to find which classes should
> be scanned for annotations. The code I have seen for this has
> hacky special cases of jar not to scan etc etc.
I made xbean-finder's ClassFinder for exactly this purpose. It uses
ASM to introspect the classes for annotations as opposed to
reflection avoiding the security issues that would associated with
loading each and every class looking for annotations.
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/
test/java/org/apache/xbean/finder/ClassFinderTest.java
Here's a good thread to give a quick read: http://mail-
archives.apache.org/mod_mbox/geronimo-xbean-dev/200610.mbox/%
3c6C2C4FB8-25E4-4B94-923F-33C778664784@visi.com%3e
With it you can search:
1. A classloader, excluding any parent classloader if you wish
2. A set of URLs (var args... so one to many)
3. A set of Classes (also var args, so one or many)
> So what we hope to provide is a mechanism to inject
> (this should be done shortly) and a pluggable mechanism
> for discovery of annotations. We will have our own simple
> implementation, but ideally the integration with geronimo would share
> the scanning that would be occurring for EJB3 etc. etc.
For the injection, we use xbean-reflect, which Dain created and I've
hacked on a bit to do field and private injection.
Here's an example of how we use it to do JNDI-based injection (sans
exception handling for brevity):
ObjectRecipe objectRecipe = new ObjectRecipe(beanClass);
objectRecipe.allow(Option.FIELD_INJECTION);
objectRecipe.allow(Option.PRIVATE_PROPERTIES);
objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);
javax.naming.Context ctx = deploymentInfo.getJndiEnc();
for (Injection injection : deploymentInfo.getInjections
()) {
String jndiName = injection.getJndiName();
Object object = ctx.lookup("java:comp/env/" +
jndiName);
objectRecipe.setProperty(injection.getName(), new
StaticRecipe(object));
}
objectRecipe.setProperty("sessionContext", new
StaticRecipe(createSessionContext()));
bean = objectRecipe.create(beanClass.getClassLoader());
Note that the objectRecipe also has methods like setFieldProperty and
setMethodProperty that allow you be more specific on where the data
should go (field vs setter). The default when using the plain
setProperty when Option.FIELD_INJECTION is enabled is to first look
for a setter then to look for a field.
-David
Re: Annotation processing
Posted by Greg Wilkins <gr...@webtide.com>.
David Blevins wrote:
>
> I took a quick look at Jetty and Tomcat source. Tomcat has some
> complete looking code for injection via JNDI, except it seems it only
> supports using annotations as the source of injection data, nothing for
> xml as the source.
>
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java?view=markup
>
>
> Jetty doesn't seem to have anything in this area. I looked for any
> references to javax.annotation and didn't find any. Greg, any thoughts
> on what your plans are in this area?
Jan,
any thoughts on what your plans are in this area?
...
We do plan to support this, but it is rather painful and
intrusive to do. The injecting the resources is not the problem
it is finding them that is an issue. It appears that we must
get more involved in the classloading to find which classes should
be scanned for annotations. The code I have seen for this has
hacky special cases of jar not to scan etc etc.
Either way, the scanning is something that in a JEE container
is something that is going to be done for other reasons and
the last thing we want is every component trying to
specialize classloading so it can separately scan all
the loaded classes.
So what we hope to provide is a mechanism to inject
(this should be done shortly) and a pluggable mechanism
for discovery of annotations. We will have our own simple
implementation, but ideally the integration with geronimo would share
the scanning that would be occurring for EJB3 etc. etc.
What are you currently planning for EJB3 annotations?
cheers
> On Dec 12, 2006, at 4:20 PM, David Blevins wrote:
>
>> On Dec 12, 2006, at 3:14 PM, David Jencks wrote:
>>> On Dec 12, 2006, at 1:07 PM, David Blevins wrote:
>>>>> 4. add objects to inject resources
>>>>
>>>> Here's where I get confused. Add objects to inject resources into
>>>> what? The confusing part is that injection is done on instances of
>>>> components (servlets, ejbs). Maybe the Tomcat/Jetty integrations
>>>> are a lot tighter than I thought they were. Are we actually
>>>> creating servlet and filter instances themselves?
>>>
>>> Definitely not for tomcat. For jetty these are created by a
>>> ServletHolder, which is wrapped into a gbean, so we could modify the
>>> object creation code. I imagine there's some similar way to
>>> customize tomcat, but I have no idea what it might be.
>>>
>>> In any case, my goal of using verbiage sufficiently general to be
>>> difficult to argue with failed :-). I have no idea what is needed
>>> nor how to do this. Do you have any advice?
>>
>> :)
>>
>> I have to imagine that both Jetty and Tomcat already have their own
>> code for injecting the items from JNDI using the standard names [1],
>> so if simply had some way to tell either of them which jndi names go
>> with which fields we'd be good to go.
>>
>> [1] Granted the spec doesn't require you to inject straight from
>> JNDI, but injection was intended to be done this way when the specs
>> were written (even SessionContext is now in JNDI) and I'd be really
>> surprised if there was anyone out there doing it differently.
>>
>> I'd be interested in what Jetty and Tomcat have in this regard.
>>
>
> I took a quick look at Jetty and Tomcat source. Tomcat has some
> complete looking code for injection via JNDI, except it seems it only
> supports using annotations as the source of injection data, nothing for
> xml as the source.
>
> http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java?view=markup
>
>
> Jetty doesn't seem to have anything in this area. I looked for any
> references to javax.annotation and didn't find any. Greg, any thoughts
> on what your plans are in this area?
>
> -David
>
>
>
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
On Dec 12, 2006, at 4:20 PM, David Blevins wrote:
> On Dec 12, 2006, at 3:14 PM, David Jencks wrote:
>> On Dec 12, 2006, at 1:07 PM, David Blevins wrote:
>>>> 4. add objects to inject resources
>>>
>>> Here's where I get confused. Add objects to inject resources
>>> into what? The confusing part is that injection is done on
>>> instances of components (servlets, ejbs). Maybe the Tomcat/Jetty
>>> integrations are a lot tighter than I thought they were. Are we
>>> actually creating servlet and filter instances themselves?
>>
>> Definitely not for tomcat. For jetty these are created by a
>> ServletHolder, which is wrapped into a gbean, so we could modify
>> the object creation code. I imagine there's some similar way to
>> customize tomcat, but I have no idea what it might be.
>>
>> In any case, my goal of using verbiage sufficiently general to be
>> difficult to argue with failed :-). I have no idea what is
>> needed nor how to do this. Do you have any advice?
>
> :)
>
> I have to imagine that both Jetty and Tomcat already have their own
> code for injecting the items from JNDI using the standard names
> [1], so if simply had some way to tell either of them which jndi
> names go with which fields we'd be good to go.
>
> [1] Granted the spec doesn't require you to inject straight from
> JNDI, but injection was intended to be done this way when the specs
> were written (even SessionContext is now in JNDI) and I'd be really
> surprised if there was anyone out there doing it differently.
>
> I'd be interested in what Jetty and Tomcat have in this regard.
>
I took a quick look at Jetty and Tomcat source. Tomcat has some
complete looking code for injection via JNDI, except it seems it only
supports using annotations as the source of injection data, nothing
for xml as the source.
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/
catalina/util/DefaultAnnotationProcessor.java?view=markup
Jetty doesn't seem to have anything in this area. I looked for any
references to javax.annotation and didn't find any. Greg, any
thoughts on what your plans are in this area?
-David
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
On Dec 12, 2006, at 3:14 PM, David Jencks wrote:
> On Dec 12, 2006, at 1:07 PM, David Blevins wrote:
>>> 4. add objects to inject resources
>>
>> Here's where I get confused. Add objects to inject resources into
>> what? The confusing part is that injection is done on instances
>> of components (servlets, ejbs). Maybe the Tomcat/Jetty
>> integrations are a lot tighter than I thought they were. Are we
>> actually creating servlet and filter instances themselves?
>
> Definitely not for tomcat. For jetty these are created by a
> ServletHolder, which is wrapped into a gbean, so we could modify
> the object creation code. I imagine there's some similar way to
> customize tomcat, but I have no idea what it might be.
>
> In any case, my goal of using verbiage sufficiently general to be
> difficult to argue with failed :-). I have no idea what is needed
> nor how to do this. Do you have any advice?
:)
I have to imagine that both Jetty and Tomcat already have their own
code for injecting the items from JNDI using the standard names [1],
so if simply had some way to tell either of them which jndi names go
with which fields we'd be good to go.
[1] Granted the spec doesn't require you to inject straight from
JNDI, but injection was intended to be done this way when the specs
were written (even SessionContext is now in JNDI) and I'd be really
surprised if there was anyone out there doing it differently.
I'd be interested in what Jetty and Tomcat have in this regard.
-David
Re: Annotation processing
Posted by David Jencks <da...@yahoo.com>.
On Dec 12, 2006, at 1:07 PM, David Blevins wrote:
>
> On Dec 12, 2006, at 9:46 AM, David Jencks wrote:
>
>> 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.
>
> See my last comment.
>
>> 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)
>
> It'd be silly to do it any other way.
>
>> 4. add objects to inject resources
>
> Here's where I get confused. Add objects to inject resources into
> what? The confusing part is that injection is done on instances of
> components (servlets, ejbs). Maybe the Tomcat/Jetty integrations
> are a lot tighter than I thought they were. Are we actually
> creating servlet and filter instances themselves?
Definitely not for tomcat. For jetty these are created by a
ServletHolder, which is wrapped into a gbean, so we could modify the
object creation code. I imagine there's some similar way to
customize tomcat, but I have no idea what it might be.
In any case, my goal of using verbiage sufficiently general to be
difficult to argue with failed :-). I have no idea what is needed
nor how to do this. Do you have any advice?
thanks
david jencks
>
>
> -David
>
Re: Annotation processing
Posted by David Blevins <da...@visi.com>.
On Dec 12, 2006, at 9:46 AM, David Jencks wrote:
> 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.
See my last comment.
> 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)
It'd be silly to do it any other way.
> 4. add objects to inject resources
Here's where I get confused. Add objects to inject resources into
what? The confusing part is that injection is done on instances of
components (servlets, ejbs). Maybe the Tomcat/Jetty integrations are
a lot tighter than I thought they were. Are we actually creating
servlet and filter instances themselves?
-David
Re: Annotation processing
Posted by Davanum Srinivas <da...@gmail.com>.
David,
We have some in Axis2's JAX-WS module as well. i need to dig into that..
-- dims
On 12/12/06, David Jencks <da...@yahoo.com> 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
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)