On 1/17/07, Tim McConnell <[EMAIL PROTECTED]> 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
