You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Tim McConnell <ti...@gmail.com> on 2007/01/17 06:02:06 UTC
JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Hi, I still think there needs to be a general consensus for the handling of annotations in Geronimo.
So, to better explain this design proposal I've
created a few simple UML diagrams that demonstrates how it might work with one of the Geronimo
builders--i.e. Tomcat.
Here's the link to the URL diagrams: http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
-- The first is just a diagram of the pertinent high-level use cases for JSR-88 1.2
-- The second is an interaction diagram of deployment at a very high-level as it currently works for
Tomcat
-- The third is the proposed interaction diagram of how deployment will generally flow with
annotations. Namely:
-- Geronimo will find/discover all the annotations in the artifact being deployed prior to
the createModule invocation on the TomcatBuilder
-- Geronimo will then update the deployment descriptor tags in the XML accordingly and then
set the Metadata-Complete tag
-- Finally, during installation of module, Geronimo will invoke Tomcat's
AnnotationProcessor implementation and pass it the array of annotations that have been discovered,
and Tomcat's AnnotationProcessor will handle handle those runtime-type annotations (e.g.,
PreDestory, PostConstruct, etc...) without corresponding deployment descriptor tags. Note also that
Tomcat's AnnotationProcessor handles the resource injection as well.
-- The fourth is just a class diagram (not yet complete) that shows the new Geronimo annotation classes
Questions:
-- Is this a pattern that can be consistently used for other builders as well like Jetty, Axis,
OpenEJB, Web Services, etc ??
-- Is it reasonable to assume that these other components will have their own AnnotationProcessor
implementation (like Tomcat) that can be invoked by Geronimo during deployment ??
--
Thanks,
Tim McConnell
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Tim McConnell <ti...@gmail.com>.
Hi Jacek, Thanks for reviewing....
Jacek Laskowski wrote:
> On 1/17/07, Tim McConnell <ti...@gmail.com> wrote:
>
>> Here's the link to the URL diagrams:
>> http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>
> They're nice! What UML tool do you use?
>
Rational Software Architect v7 (it's much improved over v6)
>> -- The first is just a diagram of the pertinent high-level use cases
>> for JSR-88 1.2
>
> I'm not sure how one can call it helpful - too many lines here and there
> ;-)
>
Well, it's primarily meant to identify the categories of use cases for each of the major interfaces
which perform deployment, and hopefully to catch anything obviously that would be missed when
testing the JSR-88 changes. So in that sense they are useful to me in any case.
>
>> -- Geronimo will then update the deployment descriptor tags
>> in the XML accordingly and then
>> set the Metadata-Complete tag
>
> I assume that you mean <metadata-complete> (all lower case) tag?
>
Yes
>> -- Finally, during installation of module, Geronimo will
>> invoke Tomcat's
>> AnnotationProcessor implementation and pass it the array of
>> annotations that have been discovered,
>> and Tomcat's AnnotationProcessor will handle handle those runtime-type
>> annotations (e.g.,
>> PreDestory, PostConstruct, etc...) without corresponding deployment
>> descriptor tags. Note also that
>> Tomcat's AnnotationProcessor handles the resource injection as well.
>
> That's the only question I meant to have asked after having taken a
> look at the UML diagram, but you seem to explain it more clearly here.
> Just to make sure I'm really following - you mean the processor which
> comes with Tomcat, don't you? Does it come with processAnnotations
> method or you hope it will?
>
Yes Tomcat has its own AnnotationProcessor with a processAnnotations method
>> -- Is this a pattern that can be consistently used for other builders
>> as well like Jetty, Axis,
>> OpenEJB, Web Services, etc ??
>
> I think so.
>
>> -- Is it reasonable to assume that these other components will have
>> their own AnnotationProcessor
>> implementation (like Tomcat) that can be invoked by Geronimo during
>> deployment ??
>
> If no processor is available the process will proceed further, won't
> it? Should we care whether or not such processors are provided by the
> external services Geronimo hosts?
>
> These are not very constructive comments for you, but let me
> understand it more clearly and hopefully will lead to some other ideas
> of yours ;-)
Your comments have been very constructive--again thanks for reviewing....
>
> Jacek
>
--
Thanks,
Tim McConnell
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 1/17/07, Tim McConnell <ti...@gmail.com> wrote:
> Here's the link to the URL diagrams: http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
They're nice! What UML tool do you use?
> -- The first is just a diagram of the pertinent high-level use cases for JSR-88 1.2
I'm not sure how one can call it helpful - too many lines here and there ;-)
> -- Geronimo will then update the deployment descriptor tags in the XML accordingly and then
> set the Metadata-Complete tag
I assume that you mean <metadata-complete> (all lower case) tag?
> -- Finally, during installation of module, Geronimo will invoke Tomcat's
> AnnotationProcessor implementation and pass it the array of annotations that have been discovered,
> and Tomcat's AnnotationProcessor will handle handle those runtime-type annotations (e.g.,
> PreDestory, PostConstruct, etc...) without corresponding deployment descriptor tags. Note also that
> Tomcat's AnnotationProcessor handles the resource injection as well.
That's the only question I meant to have asked after having taken a
look at the UML diagram, but you seem to explain it more clearly here.
Just to make sure I'm really following - you mean the processor which
comes with Tomcat, don't you? Does it come with processAnnotations
method or you hope it will?
> -- Is this a pattern that can be consistently used for other builders as well like Jetty, Axis,
> OpenEJB, Web Services, etc ??
I think so.
> -- Is it reasonable to assume that these other components will have their own AnnotationProcessor
> implementation (like Tomcat) that can be invoked by Geronimo during deployment ??
If no processor is available the process will proceed further, won't
it? Should we care whether or not such processors are provided by the
external services Geronimo hosts?
These are not very constructive comments for you, but let me
understand it more clearly and hopefully will lead to some other ideas
of yours ;-)
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Joe Bohn <jo...@earthlink.net>.
Tim McConnell wrote:
> Hi, I still think there needs to be a general consensus for the handling
> of annotations in Geronimo. So, to better explain this design proposal I've
> created a few simple UML diagrams that demonstrates how it might work
> with one of the Geronimo builders--i.e. Tomcat.
>
> Here's the link to the URL diagrams:
> http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>
> -- The first is just a diagram of the pertinent high-level use cases for
> JSR-88 1.2
>
> -- The second is an interaction diagram of deployment at a very
> high-level as it currently works for Tomcat
>
> -- The third is the proposed interaction diagram of how deployment will
> generally flow with annotations. Namely:
> -- Geronimo will find/discover all the annotations in the
> artifact being deployed prior to the createModule invocation on the
> TomcatBuilder
> -- Geronimo will then update the deployment descriptor tags in
> the XML accordingly and then set the Metadata-Complete tag
> -- Finally, during installation of module, Geronimo will invoke
> Tomcat's AnnotationProcessor implementation and pass it the array of
> annotations that have been discovered, and Tomcat's AnnotationProcessor
> will handle handle those runtime-type annotations (e.g., PreDestory,
> PostConstruct, etc...) without corresponding deployment descriptor tags.
> Note also that Tomcat's AnnotationProcessor handles the resource
> injection as well.
>
> -- The fourth is just a class diagram (not yet complete) that shows the
> new Geronimo annotation classes
>
This looks like a good approach to me for Tomcat given that they have
their own AnnotationProcessor implementation.
>
> Questions:
> -- Is this a pattern that can be consistently used for other builders as
> well like Jetty, Axis, OpenEJB, Web Services, etc ??
> -- Is it reasonable to assume that these other components will have
> their own AnnotationProcessor implementation (like Tomcat) that can be
> invoked by Geronimo during deployment ??
I don't know enough about the plans to support annotations for these
other components to give you the answer your looking for. Based upon
your investigation does it seem plausible that Jetty, Axis, etc.. will
support annotations in the same way via implementing their own
AnnotationProcessor? In either case, perhaps it would be best to
assume this approach for now so that we can integrate annotation support
for Tomcat and then determine if we need to re-evaluate the overall
structure later based upon the other components.
Thanks for digging into this Tim!
Joe
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Paul McMahan <pa...@gmail.com>.
On 1/17/07, Tim McConnell <ti...@gmail.com> wrote:
> Hi, I still think there needs to be a general consensus for the handling of annotations in Geronimo.
> So, to better explain this design proposal I've
> created a few simple UML diagrams that demonstrates how it might work with one of the Geronimo
> builders--i.e. Tomcat.
>
> Here's the link to the URL diagrams: http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>
> -- The first is just a diagram of the pertinent high-level use cases for JSR-88 1.2
>
> -- The second is an interaction diagram of deployment at a very high-level as it currently works for
> Tomcat
>
> -- The third is the proposed interaction diagram of how deployment will generally flow with
> annotations. Namely:
> -- Geronimo will find/discover all the annotations in the artifact being deployed prior to
> the createModule invocation on the TomcatBuilder
> -- Geronimo will then update the deployment descriptor tags in the XML accordingly and then
> set the Metadata-Complete tag
> -- Finally, during installation of module, Geronimo will invoke Tomcat's
> AnnotationProcessor implementation and pass it the array of annotations that have been discovered,
> and Tomcat's AnnotationProcessor will handle handle those runtime-type annotations (e.g.,
> PreDestory, PostConstruct, etc...) without corresponding deployment descriptor tags. Note also that
> Tomcat's AnnotationProcessor handles the resource injection as well.
>
> -- The fourth is just a class diagram (not yet complete) that shows the new Geronimo annotation classes
Tim, thanks for investigating this challenging area and for coming up
with a good proposal for how annotation processing can be generalized
and supported in Geronimo. I agree with your general approach of
creating a design that works for a component already in Geronimo 2.0
(tomcat) and then adapting that design to suit other components that
are on their way in (openejb) or that haven't fully implemented
annotation support yet (jetty, at least last time I checked).
> Questions:
> -- Is this a pattern that can be consistently used for other builders as well like Jetty, Axis,
> OpenEJB, Web Services, etc ??
In a previous thread I think that we reached some agreement that
annotations which have a corresponding element in the respective JEE5
schema will be merged into the DD when an application is deployed.
This will allow us to support the JSR77 requirement for providing the
DD for a resource defined in an annotation upon request. So I hope
that part of the design should look familiar to everyone.
But I agree that we need to reach some agreement that annotations like
@postConstruct and @preDestroy which cannot be merged into the DD will
be handled by the container itself. Your proposed design supports
that concept by finding the annotations in a generic way and handing
them to the container via the AnnotationProcessor interface. Tomcat
implements that interface and will handle @postConstruct, @preDestroy,
and @resource annotations accordingly.
> -- Is it reasonable to assume that these other components will have their own AnnotationProcessor
> implementation (like Tomcat) that can be invoked by Geronimo during deployment ??
If these other components can't/won't provide a native implementation
of AnnotationProcessor then can we create a new one in Geronimo's
builder module for it? As long as the component provides some public
api that accepts annotations for a given application it seems like
Geronimo could create an implementation of AnnotationProcessor that
connects the dots in the processAnnotations method.
Best wishes,
Paul
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 24, 2007, at 11:38 AM, Paul McMahan wrote:
> On 1/22/07, Jarek Gawor <jg...@gmail.com> wrote:
>> Tim,
>>
>> A couple of questions on the design/implementation:
>>
>> 1) Since the module builders will get an updated deployment
>> descriptors, in general, the annotation processors in Tomcat, Jetty,
>> Web services, EJB, etc. will just need to lookup the resources in
>> JNDI, right?
>
> IIUC the changes made last night in rev 499336 allows EjbRefBuilder to
> scan for and process @EJB annotations in webapps, making them
> available via JNDI to tomcat's annotation processor. This approach
> is similar to what Tim proposed but a little different because it
> places the responsibility of scanning for annotations into the
> builder's hands, and doesn't merge them into the DD. That leaves it
> up to Geronimo's implementation of JSR-77 to handle the merging, but
> has the advantage that error messages caused by incorrect DDs won't be
> misleading.
This is not supposed to be a final solution. It is really a hack to
make it easier for users to try out our new EJB 3 features. The
biggest issues with this hack is it scans all classes in the web
application looking for ejb-ref annotations, which means it will find
refs more than servlets. The final solution should only scan the
servlet classes plus whatever the other specs need, and the results
should be merged back in to their respective dtds.
-dain
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Paul McMahan <pa...@gmail.com>.
On 1/22/07, Jarek Gawor <jg...@gmail.com> wrote:
> Tim,
>
> A couple of questions on the design/implementation:
>
> 1) Since the module builders will get an updated deployment
> descriptors, in general, the annotation processors in Tomcat, Jetty,
> Web services, EJB, etc. will just need to lookup the resources in
> JNDI, right?
IIUC the changes made last night in rev 499336 allows EjbRefBuilder to
scan for and process @EJB annotations in webapps, making them
available via JNDI to tomcat's annotation processor. This approach
is similar to what Tim proposed but a little different because it
places the responsibility of scanning for annotations into the
builder's hands, and doesn't merge them into the DD. That leaves it
up to Geronimo's implementation of JSR-77 to handle the merging, but
has the advantage that error messages caused by incorrect DDs won't be
misleading.
Would it make sense to implement annotation support in the webservices
builder in the same way? If so then tomcat's annotation processor
should already be able to resolve and inject @WebServiceRefs via JNDI.
Best wishes,
Paul
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Tim McConnell <ti...@gmail.com>.
Hi Jarek, yes, the intent is for the module builders to get updated
deployment plan so that Tomcat, Jetty, etc.... will do the resource lookups
with JNDI just like they do currently. There has been some discussions on
the devlist (started by Sachin) as to whether we want or should accommodate
annotations for Geronimo-specific deployment descriptors. I'm not exactly
sure where it was left off, but I think the agreement was to only
accommodate the JEE5 annotations (e..g, resource-ref in your example below)
at least in the 2.0 timeframe. Thanks.
Jarek Gawor wrote:
> Tim,
>
> A couple of questions on the design/implementation:
>
> 1) Since the module builders will get an updated deployment
> descriptors, in general, the annotation processors in Tomcat, Jetty,
> Web services, EJB, etc. will just need to lookup the resources in
> JNDI, right?
>
> 2) One thing I'm unclear of is how we are going to deal with the
> geronimo-*.xml deployment descriptors? For example, if a service wants
> to access the system data source it needs to provide the following
> information (in geronimo-web.xml file):
>
> <web-app>
> ....
> <dependencies>
> <dependency>
> <groupId>org.apache.geronimo.configs</groupId>
> <artifactId>system-database</artifactId>
> </dependency>
> </dependencies>
> ....
> <resource-ref>
> <ref-name>jdbc/MyDataSource</ref-name>
> <resource-link>SystemDatasource</resource-link>
> </resource-ref>
> </web-app>
>
> I think the annotation.mappedName can be used for the resource-ref
> info but what about the dependency? Will user still need to provide
> that or Geronimo will attempt to figure it out somehow?
>
> Thanks,
> Jarek
>
> On 1/17/07, Tim McConnell <ti...@gmail.com> wrote:
>> Hi, I still think there needs to be a general consensus for the
>> handling of annotations in Geronimo.
>> So, to better explain this design proposal I've
>> created a few simple UML diagrams that demonstrates how it might work
>> with one of the Geronimo
>> builders--i.e. Tomcat.
>>
>> Here's the link to the URL diagrams:
>> http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>>
>> -- The first is just a diagram of the pertinent high-level use cases
>> for JSR-88 1.2
>>
>> -- The second is an interaction diagram of deployment at a very
>> high-level as it currently works for
>> Tomcat
>>
>> -- The third is the proposed interaction diagram of how deployment
>> will generally flow with
>> annotations. Namely:
>> -- Geronimo will find/discover all the annotations in the
>> artifact being deployed prior to
>> the createModule invocation on the TomcatBuilder
>> -- Geronimo will then update the deployment descriptor tags
>> in the XML accordingly and then
>> set the Metadata-Complete tag
>> -- Finally, during installation of module, Geronimo will
>> invoke Tomcat's
>> AnnotationProcessor implementation and pass it the array of
>> annotations that have been discovered,
>> and Tomcat's AnnotationProcessor will handle handle those runtime-type
>> annotations (e.g.,
>> PreDestory, PostConstruct, etc...) without corresponding deployment
>> descriptor tags. Note also that
>> Tomcat's AnnotationProcessor handles the resource injection as well.
>>
>> -- The fourth is just a class diagram (not yet complete) that shows
>> the new Geronimo annotation classes
>>
>>
>> Questions:
>> -- Is this a pattern that can be consistently used for other builders
>> as well like Jetty, Axis,
>> OpenEJB, Web Services, etc ??
>> -- Is it reasonable to assume that these other components will have
>> their own AnnotationProcessor
>> implementation (like Tomcat) that can be invoked by Geronimo during
>> deployment ??
>>
>> --
>> Thanks,
>> Tim McConnell
>>
>
--
Thanks,
Tim McConnell
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Jarek Gawor <jg...@gmail.com>.
Tim,
A couple of questions on the design/implementation:
1) Since the module builders will get an updated deployment
descriptors, in general, the annotation processors in Tomcat, Jetty,
Web services, EJB, etc. will just need to lookup the resources in
JNDI, right?
2) One thing I'm unclear of is how we are going to deal with the
geronimo-*.xml deployment descriptors? For example, if a service wants
to access the system data source it needs to provide the following
information (in geronimo-web.xml file):
<web-app>
....
<dependencies>
<dependency>
<groupId>org.apache.geronimo.configs</groupId>
<artifactId>system-database</artifactId>
</dependency>
</dependencies>
....
<resource-ref>
<ref-name>jdbc/MyDataSource</ref-name>
<resource-link>SystemDatasource</resource-link>
</resource-ref>
</web-app>
I think the annotation.mappedName can be used for the resource-ref
info but what about the dependency? Will user still need to provide
that or Geronimo will attempt to figure it out somehow?
Thanks,
Jarek
On 1/17/07, Tim McConnell <ti...@gmail.com> wrote:
> Hi, I still think there needs to be a general consensus for the handling of annotations in Geronimo.
> So, to better explain this design proposal I've
> created a few simple UML diagrams that demonstrates how it might work with one of the Geronimo
> builders--i.e. Tomcat.
>
> Here's the link to the URL diagrams: http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>
> -- The first is just a diagram of the pertinent high-level use cases for JSR-88 1.2
>
> -- The second is an interaction diagram of deployment at a very high-level as it currently works for
> Tomcat
>
> -- The third is the proposed interaction diagram of how deployment will generally flow with
> annotations. Namely:
> -- Geronimo will find/discover all the annotations in the artifact being deployed prior to
> the createModule invocation on the TomcatBuilder
> -- Geronimo will then update the deployment descriptor tags in the XML accordingly and then
> set the Metadata-Complete tag
> -- Finally, during installation of module, Geronimo will invoke Tomcat's
> AnnotationProcessor implementation and pass it the array of annotations that have been discovered,
> and Tomcat's AnnotationProcessor will handle handle those runtime-type annotations (e.g.,
> PreDestory, PostConstruct, etc...) without corresponding deployment descriptor tags. Note also that
> Tomcat's AnnotationProcessor handles the resource injection as well.
>
> -- The fourth is just a class diagram (not yet complete) that shows the new Geronimo annotation classes
>
>
> Questions:
> -- Is this a pattern that can be consistently used for other builders as well like Jetty, Axis,
> OpenEJB, Web Services, etc ??
> -- Is it reasonable to assume that these other components will have their own AnnotationProcessor
> implementation (like Tomcat) that can be invoked by Geronimo during deployment ??
>
> --
> Thanks,
> Tim McConnell
>
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by Tim McConnell <ti...@gmail.com>.
anita kulshreshtha wrote:
> --- Tim McConnell <ti...@gmail.com> wrote:
>
>> Hi, I still think there needs to be a general consensus for the
>> handling of annotations in Geronimo.
>> So, to better explain this design proposal I've
>> created a few simple UML diagrams that demonstrates how it might work
>> with one of the Geronimo
>> builders--i.e. Tomcat.
>>
>> Here's the link to the URL diagrams:
>> http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>>
>> -- The first is just a diagram of the pertinent high-level use cases
>> for JSR-88 1.2
>>
>> -- The second is an interaction diagram of deployment at a very
>> high-level as it currently works for
>> Tomcat
>>
>> -- The third is the proposed interaction diagram of how deployment
>> will generally flow with
>> annotations. Namely:
>> -- Geronimo will find/discover all the annotations in the
>> artifact being deployed prior to
>> the createModule invocation on the TomcatBuilder
>> -- Geronimo will then update the deployment descriptor tags
>> in the XML accordingly and then
>> set the Metadata-Complete tag
>> -- Finally, during installation of module, Geronimo will
>> invoke Tomcat's
>> AnnotationProcessor implementation and pass it the array of
>> annotations that have been discovered,
>> and Tomcat's AnnotationProcessor will handle handle those
>> runtime-type annotations (e.g.,
>> PreDestory, PostConstruct, etc...) without corresponding deployment
>> descriptor tags. Note also that
>> Tomcat's AnnotationProcessor handles the resource injection as well.
>
> IIUC Tomcat's AnnotationProcessor will also be scanning
> WEB-INF/classes and WEB-INF/lib and discovering these annotations. Is
> is not going to provide a JSR77 friendly DD back to us? Is that why we
> must duplicate some of the work?
>
> Thanks
> Anita
>
Hi Anita, the current plan is to use David Blevin's ClassFinder code from XBEAN project to help
create a "JSR-77 friendly" DD when necessary and/or appropriate for Geronimo. And hopefully by using
Tomcat's own annotation processor we'll mitigate duplication of code/work.....
>> -- The fourth is just a class diagram (not yet complete) that shows
>> the new Geronimo annotation classes
>>
>>
>> Questions:
>> -- Is this a pattern that can be consistently used for other builders
>> as well like Jetty, Axis,
>> OpenEJB, Web Services, etc ??
>> -- Is it reasonable to assume that these other components will have
>> their own AnnotationProcessor
>> implementation (like Tomcat) that can be invoked by Geronimo during
>> deployment ??
>>
>> --
>> Thanks,
>> Tim McConnell
>>
>
>
>
>
> ____________________________________________________________________________________
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.
> http://tv.yahoo.com/
>
--
Thanks,
Tim McConnell
Re: JSR-88 1.2 Proposed Design for Geronimo Annotation Processing
Posted by anita kulshreshtha <a_...@yahoo.com>.
--- Tim McConnell <ti...@gmail.com> wrote:
> Hi, I still think there needs to be a general consensus for the
> handling of annotations in Geronimo.
> So, to better explain this design proposal I've
> created a few simple UML diagrams that demonstrates how it might work
> with one of the Geronimo
> builders--i.e. Tomcat.
>
> Here's the link to the URL diagrams:
> http://cwiki.apache.org/GMOxDEV/jsr-88-12.html
>
> -- The first is just a diagram of the pertinent high-level use cases
> for JSR-88 1.2
>
> -- The second is an interaction diagram of deployment at a very
> high-level as it currently works for
> Tomcat
>
> -- The third is the proposed interaction diagram of how deployment
> will generally flow with
> annotations. Namely:
> -- Geronimo will find/discover all the annotations in the
> artifact being deployed prior to
> the createModule invocation on the TomcatBuilder
> -- Geronimo will then update the deployment descriptor tags
> in the XML accordingly and then
> set the Metadata-Complete tag
> -- Finally, during installation of module, Geronimo will
> invoke Tomcat's
> AnnotationProcessor implementation and pass it the array of
> annotations that have been discovered,
> and Tomcat's AnnotationProcessor will handle handle those
> runtime-type annotations (e.g.,
> PreDestory, PostConstruct, etc...) without corresponding deployment
> descriptor tags. Note also that
> Tomcat's AnnotationProcessor handles the resource injection as well.
IIUC Tomcat's AnnotationProcessor will also be scanning
WEB-INF/classes and WEB-INF/lib and discovering these annotations. Is
is not going to provide a JSR77 friendly DD back to us? Is that why we
must duplicate some of the work?
Thanks
Anita
>
> -- The fourth is just a class diagram (not yet complete) that shows
> the new Geronimo annotation classes
>
>
> Questions:
> -- Is this a pattern that can be consistently used for other builders
> as well like Jetty, Axis,
> OpenEJB, Web Services, etc ??
> -- Is it reasonable to assume that these other components will have
> their own AnnotationProcessor
> implementation (like Tomcat) that can be invoked by Geronimo during
> deployment ??
>
> --
> Thanks,
> Tim McConnell
>
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/