https://issues.apache.org/bugzilla/show_bug.cgi?id=48414
--- Comment #3 from david jencks <djen...@apache.org> 2009-12-20 02:28:54 UTC
---
Looking at the javadoc for Class.forName(String className) gives
Returns the Class object associated with the class or interface with the given
string name. Invoking this method is equivalent to:
Class.forName(className, true, currentLoader)
where currentLoader denotes the defining class loader of the current class.
Lets suppose we have catalina jar containing StandardContext, InstanceListener,
ContainerListener, and NamingContextListener, and an integration jar containing
GeronimoStandardContext extends StandardContext and
DispatchListener implements InstanceListener
Furthermore lets suppose these are separate bundles in an osgi environment
(i.e. the integration bundle is not a fragment bundle extending catalina.jar,
but a separate bundle)
I did a little experimentation in the debugger.
It turns out that:
1. Class.forName(String className)
here means
Class.forName(className, true, StandardContext.class.getClassLoader())
and not
Class.forName(className, true, GeronimoStandardContext.class.getClassLoader())
even though the current object is an instance of GeronimoStandardContext.
So, there is no chance of loading any classes from the integration bundle.
Replacing the code with Class.forName(className, true,
StandardContext.class.getClassLoader()) won't work.
2. replacing the code with
Class.forName(className, true, GeronimoStandardContext.class.getName()) doesn't
work either, since in osgi this classloader can only load classes from the jar
GeronimoStandardContext is in, not catalina.jar.
If bundle is the Bundle for the integration jar,
bundle.loadClass(className) does work for all listeners, whether from catalina
or the integration.
So, AFAICT the choices are:
1. Require any listeners in an osgi environment to be in fragment bundles
associated with catalina.jar
2. Allow some other way to load classes in an osgi environment, such as from an
appropriate bundle.
Since I'm not really interested in telling tomcat how to load classes for
itself, I suggested using the existing integration point of InstanceManager
which allows integrations to specify how to load classes for themselves. I
realize that the instance manager method in my patch allows access to
application classes, and I'm not 100% sure of how tomcat distinguishes between
system and application classes, so if it's a bad idea to allow applications to
contain these listener classes, I suggested adding a newSystemInstance(String
className) to the InstanceManager interface. However I really hope you'll
agree that only allowing extension listeners in fragment bundles is
unnecessarily limiting.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
