tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Date Thu, 24 Dec 2009 22:27:09 GMT
I'd like to encourage a little more discussion on this topic.   Mark  
commented on the bugzilla entry to the effect, IIUC, that he thought  
this was a geronimo problem.  I did some more experimentation and I'm  
pretty sure it has nothing to do with geronimo specifically, but  
relates to how Class.forName works in osgi.

I've concluded from my experiments that Class.forName in osgi will  
only load classes from the current bundle and not from any bundles  
wired to the current bundle through package-imports.  I think this  
means that with the current code all listeners have to be in the same  
jar as the catalina.jar classes or in a fragment bundle attached to  
it.  I haven't tried using a fragment bundle so I don't know if it  
would actually work.

So, my conclusion is that the current code forces:
  if you want listeners that don't come with tomcat, you have to put  
them in a fragment bundle or repackage all of tomcat to include them.   
Is this really the policy tomcat wants to adopt towards osgi  
environments?  I would think that delegating all reflective class  
loading to a pluggable component would be a more extension-friendly  

BTW, has anyone tried to find out if the split into catalina.jar and  
coyote.jar works in osgi?

david jencks

On Dec 19, 2009, at 5:12 PM, David Jencks wrote:

> In the tomcat-7 geronimo/osgi integration we've run into a problem  
> when tomcat loads listener classes using Class.forName.  Using the  
> InstanceManager to just create the objects works fine for us.
> In geronimo at the moment the InstanceManager has access to both  
> application and system classes, so it can load just about anything  
> that is supplied as a listener class.  If listeners are supposed to  
> only be system classes, perhaps adding another method to  
> InstanceManager to create system objects would be appropriate.
> If changing this is unacceptable for some reason we do have a couple  
> of other solutions available such as overriding the method or adding  
> the geronimo listener classes in a fragment bundle, but I think  
> using the InstanceManager would be a more elegant solution.
> See (patch  
> included) and
> Many thanks!
> david jencks
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message