geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Annotation & Injection in Geronimo + Tomcat + Jasper
Date Fri, 23 Mar 2007 17:37:42 GMT
I've been working on connecting geronimo annotation processing and  
injection support to tomcat and jasper and studying how the current  
tomcat and jasper support this and have been working on a proposal  
for changing how tomcat deals with this area that I hope will be seen  
as an improvement.

I've generally removed exceptions from the method signatures below in  
an attempt to make the situation a little clearer.

As far as I can tell (so far) there are four kinds of objects  
relevant here:

The first three are created more or less directly by tomcat whereas  
tags are created by some code in jasper and by code generated by jasper.

Currently tomcat and jasper use a very wide variety of techniques to  
create the objects and then use an instance of

public interface AnnotationProcessor {
     public void postConstruct(Object instance);
     public void preDestroy(Object instance);
     public void processAnnotations(Object instance);

in a sequence like this:

Object o = <create a new instance through various kinds of magic>

When its time to toss the object they call

What I would like to do is replace the AnnotationProcessor with a  
different simpler interface like this: (the name is not important...)

public interface LifecycleProvider {
     Object newInstance(String fqcn, ClassLoader classLoader);
     void destroyInstance(Object o);

The idea is that the newInstance method does everything necessary to  
construct a fully injected and post-constructed instance, and the  
destroyInstance does everything necessary to stop it.  Its very easy  
to write an adapter between this proposed interface and the  
AnnotationProcessor interface, so tomcat and jasper would continue to  
support the AnnotationProcessor approach just as they do today.

The reason use this interface from geronimo's perspective is that we  
have some very nice code that can do the object creation and  
injection in one step.  It's designed to support constructor  
injection as well as property injection, so the object instance  
construction and injection aren't really separable.

Aside from altruism the reason I think the tomcat developers might be  
interested in this is that there is such a wide variety of code in  
the <create a new instance through various kinds of magic> step and  
it looks to me as if this is most likely a consequence of less and  
less attention getting paid as new kinds of objects need to be  
created.  This would put all the managed object creation code in one  
place so each object creation would get the same level of attention.

For instance, while listeners and tags are created with a simple  
clazz.newInstance(), the servlet construction code checks a lot of  
conditions before deciding how to construct the object: in particular  
security settings might cause it to be in a PrivilegedAction and if  
it is available in the same classloader as tomcat then special  
actions are taken.  While I don't entirely understand the point of  
some of this it seems highly unlikely that it is appropriate only for  
servlets and not filters, listeners and tags.

I've been working on this approach for about a week now and think I  
have most everything related to tomcat changes working.  There are  
still some problems with things like tld schema upgrades which are  
not related to tomcat code.  I would be more comfortable proposing  
this to the tomcat community after we've ironed out more of the  
geronimo problems, but I'd like to start some discussion on this and  
also commit my code so everyone can see at least the geronimo side  
clearly.  Since my copy of geronimo doesn't build without my changes  
to tomcat/jasper, to proceed with this I need to get my version of  
tomcat out somehow.

Here are some possibilities I've thought of, maybe someone can think  
of something even better:

- attach my tomcat patch to a geronimo jira issue, maybe check the  
patch into svn somewhere, build tomcat + jasper locally, and put them  
into our "repository" module (mabye with source jars if I can figure  
out how to create them)

- svn copy tomcat to our tree and apply the patch, check it in, and  
push "org.apache.geronimo.tomcat/jasper" jars to the snapshot repo

In any case I'd prefer to check my geronimo changes into trunk in the  
optimistic expectation that the Tomcat community will accept  
something like this proposal and that if they don't it will still be  
easier to adapt to the AnnotationProcessor approach in trunk than to  
deal with a geronimo branch.

Anyway I started GERONIMO-3010 and I'll attach my tomcat patches  
there even though they aren't quite ready to propose to the tomcat  
community.  (AFAIK they work but especially the jasper code  
generation needs to be cleaned up)


david jencks

View raw message