tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
Date Tue, 05 Jan 2010 20:26:46 GMT
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 


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

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

View raw message