You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Tim Whittington <ti...@orionhealth.com> on 2010/01/04 03:46:49 UTC
Re: Problem loading classes with Class.forName() in
StandardContext.createWrapper()
We've experienced similar issues integrating lots of third party libraries (Tomcat being one of them) into our OSGi runtime.
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.
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.
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).
cheers
tim
----- Original Message -----
From: "David Jencks" <da...@yahoo.com>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Sent: Friday, 25 December, 2009 11:27:09 AM GMT +12:00 New Zealand
Subject: Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
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
approach.
BTW, has anyone tried to find out if the split into catalina.jar and
coyote.jar works in osgi?
thanks
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 https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 (patch
> included) and https://issues.apache.org/jira/browse/GERONIMO-4992
>
> Many thanks!
> david jencks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
On 01/05/2010 12:38 PM, Mark Thomas wrote:
> On 05/01/2010 17:41, David Jencks wrote:
>
>> On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote:
>>
>>> 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.
>>
> The new patches make it clear that these are what I called container
> related instances. In this case the InstanceManager feels like the wrong
> place to do this. InstanceManagers are per web application and not
> really intended for container level objects.
>
> It is also still not clear why some container objects were selected for
> this new instantiation method and some not. This seems like something
> you would want for all container objects, rather than a sub-set.
>
> Since these are container objects and the default implementation is to
> call containerClassLoader.loadClass(className) I started to wonder if
> the container class loader might not be a better point to implement this
> integration. Something along the lines of a modified ClassLoaderFactory
> that returned a ClassLoader instance that new how to look things up via
> OSGI services and/or other OSGI bundles.
>
agree with Mark, just make the common/shared/server class loaders
configurable/injectable
Filip
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Posted by Mark Thomas <ma...@apache.org>.
On 05/01/2010 17:41, David Jencks wrote:
>
> On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote:
>> 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.
The new patches make it clear that these are what I called container
related instances. In this case the InstanceManager feels like the wrong
place to do this. InstanceManagers are per web application and not
really intended for container level objects.
It is also still not clear why some container objects were selected for
this new instantiation method and some not. This seems like something
you would want for all container objects, rather than a sub-set.
Since these are container objects and the default implementation is to
call containerClassLoader.loadClass(className) I started to wonder if
the container class loader might not be a better point to implement this
integration. Something along the lines of a modified ClassLoaderFactory
that returned a ClassLoader instance that new how to look things up via
OSGI services and/or other OSGI bundles.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Posted by David Jencks <da...@yahoo.com>.
I've uploaded a couple patches to https://issues.apache.org/bugzilla/show_bug.cgi?id=48414
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.
thanks
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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Posted by David Jencks <da...@yahoo.com>.
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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org