The problem here is the same one, I think. Yes, the class loader has been
set for this Thread, but the class DCTest was loaded by the system
classloader, so the system classloader is the one that attempts to resolve
any classes directly referenced.
This, however, seems to obviate the purpose of the setContextClassLoader
method. What exactly is it good for?
Do you think this code would work if modified as below (I haven't tested
this)?
Here, the current thread's (i.e.,the main thread) classloader is set to be
the URLClassLoader "cl"...
but cl's parent is the System classloader, so it should be resolving classes
too.
Also, since DCTest is loaded using cl, any classes loaded from code within
DCTest MUST use cl to resolve classes, correct?
Maybe the only way to solve this problem is to use a "bootstrap" class
loader with the system classloader as its parent, as in the code below?
public class mainClass{
public static void main( String args[] ){
// Commandline argument is url to load classes from
java.net.URL urls[] = new java.net.URL[1];
urls[0] = new java.net.URL( args[0] );
ClassLoader cl = new
ava.net.URLClassLoader( urls,ClassLoader.getSystemClassLoader );
Thread.getCurrentThread().setContextClassLoader( cl );
cl.loadClass( "DCTest");
Thread t = new Thread( new DCTest() );
t.start();
while( t.isAlive() );
}
}
public class DCTest implements Runnable
{
public void run()
{
org.jboss.logging.Log m = new org.jboss.logging.Log();
}
}
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tom Cook
Sent: Thursday, February 15, 2001 3:20 PM
To: JBoss-User
Subject: RE: [jBoss-User] DYNAMIC CLASSLOADING
On Thu, 15 Feb 2001, you wrote:
> this is exactly what Im talking about, tom. Yes, the interface class is
> loaded by the class loader cl, and the object "homeClass" is valid. but
when
> you go referring directly to the class (eg. "my.home.interface.class",
> casting to (my.home.interface), declaring a variable my.home.interface if)
> the JVM will not use the class loaded by cl, it will try to load the
> my.home.interface class AGAIN using the defining classloader for whatever
> class we are looking at here. Which will fail because the defining
> classloader cant see my.home.interface.
>
> your code would be fine if the last line read:
> Object if = PortableRemoteObject.narrow( o, homeClass );
But the defining class loader should be the context class loader for the
thread, should it not? Which I have just set to cl.
After some short tests, it would seem this is not the case. In fact, this
code
also does not work:
public class DCTest implements Runnable
{
public static void main( String args[] )
throws Throwable
{
java.net.URL urls[] = new java.net.URL[1];
urls[0] = new java.net.URL( args[0] ); // Commandline argument is url
to
load classes from
ClassLoader cl = new java.net.URLClassLoader( urls );
System.out.println( "Set class loader and security manager." );
System.out.println( cl.getResource( "org/jboss/logging/Log.class" ).toString
() );
Class homeClass = cl.loadClass( "org.jboss.logging.Log" );
System.out.println( "Class loaded." );
Thread t = new Thread( new DCTest() );
t.setContextClassLoader( cl );
t.start();
while( t.isAlive() );
}
public void run()
{
org.jboss.logging.Log m = new org.jboss.logging.Log();
}
}
again throwing an exception when the direct reference is made. Is there no
way
around this, besides using reflection?
Tom
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
