geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Annotation & Injection in Geronimo + Tomcat + Jasper
Date Sat, 24 Mar 2007 15:48:28 GMT
Looks good, I'm not really the annotations person, but I will put it 
directly in his hands.
The word "lifecycle" is widely used in Tomcat, so we might have to come 
up with a better name, to avoid confusion.


David Jencks wrote:
> 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:
> servlets
> filters
> listeners
> tags
> 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>
> annotationProcessor.processAnnotations(o);
> annotationProcessor.postConstruct(o);
> When its time to toss the object they call
> annotationProcessor.preDestroy(o);
> 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)
> Thoughts?
> thanks
> david jencks
> --No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.17/730 - Release Date: 
> 3/22/2007 7:44 AM

View raw message