tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Annotation processing - Geronimo injection
Date Tue, 10 Apr 2007 20:42:22 GMT
I've come up with a couple more patches that try to address your  
This one eliminates backwards compatibility support for  
AnnotationProcessor and eliminates the replaceable aspects of jasper  
InstanceManagerFactory, just leaving a static method for obtaining  
the InstanceFactory.  This is decidedly less flexible than the  
previous implementation and now requires jasper to be run in a  
container that supplies an InstanceManager.  There are still separate  
interfaces for InstanceManagers for catalina and jasper.  I think  
this is a considerably superior design than the next one...

This has 2 interfaces, 1 implementation (in tomcat, there's an unused  
impl in jasper, see below). 
In addition, this one combines the InstanceManager interfaces.  I  
think this is a bad idea because it forces jasper to use an interface  
shared with catalina, which the previous patch does not.  This makes  
catalina marginally more complicated when used as a standalone  
container for jasper but makes it possible to use jasper outside  
catalina without any catalina classes.  Note also that the previous  
(3c) patch allows use of tomcat embedded in a container that supplies  
its own InstanceManager implementation without pulling in any jasper  
classes at runtime.

This has 1 interface, 1 implementation.

Both of these include a jasper DefaultInstanceManager that isn't  
used, but could be by a project that wants to install jasper with no  
annotation support.

I'd like to explore exactly how jasper creates classloaders and  
whether its possible to use class reloading features of modern jvms  
to eliminate the need to allow replacing the classloader in the  
jasper InstanceManager at runtime.  Unfortunately I doubt I'll have  
time for this in the next month or so.

On Apr 6, 2007, at 5:03 AM, Remy Maucherat wrote:

> David Jencks wrote:
>> but I won't put it in the org.apache package.
> There are not too many solutions to this problem, and  
> (unfortunately for you, apparently) I think it's the most  
> appropriate, or least inappropriate if you prefer. I was already  
> aware it was possible to have one interface in Jasper and implement  
> it in Catalina, or one interface in Catalina and use it in Jasper,  
> and it would work ;)

yes, and I prefer 2 interfaces with the possiblity of supplying  
separate implementations.  This makes catalina's standalone life  
slightly more complicated but jasper's life outside catalina simpler  
>>> - I still don't know if I agree with removing the security checks  
>>> out of Catalina, merging checks between filters and servlets, etc
>> I think that the security checks and related code are really  
>> specific to the tomcat classloader and you shouldn't force them on  
>> containers embedding tomcat that use different classloaders.  As  
>> far as uniformizing the code between servlets, filters, and  
>> listeners, I still don't understand the problem.  You might well  
>> be right, but I'd really appreciate concrete details on why some  
>> checks are appropriate for servlets and not listeners or filters.   
>> Since all of these objects are only created once (except for  
>> single-thread-model servlets, which have all the checks anyway) I  
>> don't really see why a slight difference in startup speed would  
>> outweigh the simplicity of uniform code and relative ease of  
>> understanding of having the object creation policy in one place.
> I don't know for sure about that, I would have to look at what gets  
> run in each case. Maybe the implementation in the proposed patch is  
> fine.

I could have missed something, but so far I think what I'm proposing  
is OK.
>>> - Class hierarchy for InstanceManager -> meh (although I suppose  
>>> it perfectly fits your needs, though ...)
>> I agree... Geronimo implements its own InstanceManagers for tomcat  
>> and jasper, so we don't have that problem.  I'd be perfectly happy  
>> to drop support for AnnotationProcessor entirely, but I kinda  
>> doubt you would like it so much :-)
> It does not make any difference, really: if the API changes  
> significantly, there's no need to keep the old API and provide fake  
> compatibility, it would not really help IMO.
> I was complaining about the 2 interfaces + 1 abstract + 2 impls + 1  
> factory (maybe I forgot some). This is overengineered (for Tomcat  
> at least) IMO. Personally, the thing that I would like would be at  
> most: 1 shared interface, 1 abstract, 1 impl. OTOH, I think I  
> accept the idea of the InstanceManager interface.
> Overall, thanks for the patch, it gives a very good basis for work  
> (esp if you did test it).
>>> To be honest, this whole stuff may be material. We'll see.
>> thanks!
> The first decision is to see if the API change is going to be  
> acceptable in 6.0.x.

Looking forward to your comments...

> Rémy

david jencks

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message