tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Date Mon, 04 Jan 2010 10:56:32 GMT
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.


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

View raw message