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 Tue, 05 Jan 2010 19:26:09 GMT
I've uploaded a couple patches to

  with a new newSystemInstance method.  I'm not sure why this doesn't  
need to be in a protected block like much of the code that creates  
objects for the app, but the original code wasn't in such a block so  
I'm assuming it's not really needed.

david jencks

On Jan 5, 2010, at 9:41 AM, David Jencks wrote:

> On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote:
>> On 04/01/2010 02:46, Tim Whittington wrote:
>> No need to re-post. A ping would have sufficed.
>>> We've experienced similar issues integrating lots of third party  
>>> libraries (Tomcat being one of them) into our OSGi runtime.
>> Thanks for your input. I can't speak for the other Tomcat  
>> committers but
>> I know very little about OSGI so it is useful to have input from  
>> those
>> more experienced.
>>> Essentially this boils down to OSGi liking extension functionality  
>>> to be provided by instantiation in the providing bundles, and  
>>> publication using OSGi services.
>>> (i.e. pure OSGi services or declarative services etc.). Put  
>>> another way, the concepts of global application classloaders where  
>>> Class.forName works (ala Java EE etc.) break down in OSGi.
>>> Libraries that use the TCCL in preference to Class.forName help,  
>>> but in cases like the one you describe where there's no direct  
>>> invocation from the bundle that has access to the classes it  
>>> doesn't help. Fragment bundles (and Eclipse specific buddy  
>>> classloaders) also help, and we've had to use them with tools like  
>>> Hibernate, but they're less than ideal.
>>> I think the conclusion you've reached is correct - either fragment  
>>> bundles (which is a sub-optimal solution) or a pluggable extension  
>>> loading framework could be the solution.
>> OK. The consensus amongst those that know OSGI seems to be some  
>> form for
>> pluggable extension point.
>>> I believe we ran into issues like this when integrating Tomcat 5.5  
>>> into our OSGi runtime - we had to patch up the web app  
>>> ClassLoaders at runtime to make taglib loading work.
>>> In that case we were able to wrap the ClassLoaders with the help  
>>> of some declarative metadata in bundles containing taglibs.
>>> If you can tell which bundles can contain implementions of  
>>> whatever it is you're trying to instantiate, you can construct a  
>>> ClassLoader spanning those bundles yourself and use that (you'd  
>>> only want to use it for loading these extensions, as it defeats  
>>> the purpose/nature of OSGi to some extent to do this).
>>> It might be that the web application bundles would be all you need  
>>> (and the upcoming OSGi Enterprise Spec will give you a standard  
>>> way of locating these), and that'd probably be a reasonable  
>>> limitation, or you could accomodate applications partitioned to a  
>>> finer degree by some additional marker to include other bundles.
>>> The other, more OSGi approach would be for listeners to be  
>>> published as OSGi services with target properties, that are then  
>>> just looked up by name by the OSGi version of the extension loader  
>>> (as opposed to instantiating them).
>>> i.e. an instance of the Listener interface is published by a  
>>> bundle as an OSGi service with a property  
>>> tomcatClassName=org.myproject.impl.MyListener. The extension  
>>> loader then looks up the service with a property filter on  
>>> 'tomcatClassName' to find the available extension.
>>> OSGi apps using Tomcat would simply publish these using  
>>> Declarative Services or similar, and this would be a very natural  
>>> approach for an OSGi app.
>> Using Services does seem more in the spirit of OSGI.
>>> With this latter approach you have delightful lifecycle management  
>>> issues because of the dynamic nature of OSGi (extension bundles  
>>> starting after the Tomcat bundles for instance). We solve some of  
>>> these with a combination of declarative only metadata (using the  
>>> Eclipse Extension Registry) to advertise extension existence on  
>>> bundle resolution, and Declarative Services to instantiate and  
>>> publish the actual extension, and some by having the framework  
>>> accept dynamic injection of extensions (Listeners come and go).
>> Glad I don't have to worry about those issues :)
>> The main purpose of the InstanceManager is meet some of the  
>> requirements
>> for annotations support. As such, it is only used for instances  
>> that may
>> have annotations. There is one InstanceManager instance per web  
>> application.
>> One thing that isn't clear to me is whether the requirement is for an
>> extension point for web application related instances (ie things  
>> that in
>> a J2EE environment would be bundled in the WAR) or for container  
>> related
>> instances such as LifecycleListeners. The current patch in bug 48414
>> seems to focussed on Tomcat internals and I don't understand how the
>> line was drawn between what to access via the InstanceManager and  
>> what
>> not to.
> Thanks for taking another look at this subject. I've been thinking  
> of the InstanceManager as the extension point for creating objects  
> by reflection rather than as the annotation handler, perhaps because  
> of how the Geronimo InstanceManager happens to be implemented.  So,  
> it seems to me that adding a newSystemInstance method to it for  
> creating objects that are expected to come from the system rather  
> than application classes is reasonable.  I'll try to come up with a  
> patch using this additional method in the next day or two.
> thanks again!
> david jencks
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message