commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [discovery] How to get class context?
Date Fri, 28 Jun 2002 21:46:55 GMT

>I know I must be really naïve to have to ask this, but since I don't
>understand classloader as well as I wished, I just can resist the
>opportunity to learn something. Why can't you get the caller's
>classloader from the SPIContext or Class passed into the
>ServiceFinder.find method?

Assuming that we (ultimately) change LogFactory to use the ServiceFinder.
Then we might have:

    class Caller {
        LogFactory logFactory;

        static {
            Properties props = new Properties();
            LogFactory logFactory = LogFactory.getInstance(props);

How does the discovery code obtain 'Caller'?  The caller shouldn't be
LogFactory, as that is just a wrapper for ServiceFinder.  That's also
useful, and should be tried.  What Costin was suggesting was that we try to
load the class using the same classloader that loaded Caller (Caller.
getClassLoader()).  This is especially useful inside a managed environment
(i.e. J2EE application) where the class loader that loaded Caller is more
likely to find a factory, as in the example above.  Using the SPI's
classloader (LogFactory.getClassLoader()) is not good enough, if SPI was
loaded by the system classloader, it will not see my.local.LogFactoryImpl.
Remember that we look UP the tree, but not DOWN.  Consider the following
(Loosely, this misses many details) which represents a realistic situation:

System Loader (loads LogFactory.class (abstract or interface),
ServiceFinder, etc).
Application Loader (could load my.local.LogFactoryImpl).
Module Loader (could load Caller)

Caller.getClassLoader() would find Caller and defer to it's parent loaders
to find LogFactoryImpl, LogFactory, ServiceFinder, etc.  Net: using this
class loader will load all classes.

Calling LogFactory.getClassLoader() would find LogFactory, ServiceFinder,
etc).  Net: would not find Caller.

Now consider if the tree has branches... there are different paths to
try... so using JUST Caller's class loader may miss something, so we try


Richard A. Sitze  
CORBA Interoperability & WebServices
IBM WebSphere Development
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message