Tom - essentially you do have to use reflection at some point. But, heres
what I dont understand:
If I have class A and B, where A refers directly to B in the code, then I
have to have B in the classpath in order to compile A! So then, why would
I want to distribute A without B, and then use dynamic classloading to
download B from the network? Dynamic classloading is useful primarily when
you dont know at compile time what classes you will be dealing with - in
which case you have to use reflection anyway.
That said, there is a way to do it relatively painlessly. Suppose you have
classes A and B as above. Instead of putting main() in A, put main in some
3rd class C. Then load A dynamically with URLClassLoader, and instaniate it
using reflection. B will then be loaded by the same classloader and
everyone is happy. This is just what Jboss does, right? It creates a
classloader that sees your ejb jar. Then it instantiates the ejb class in
the classloader, and the rest of the classes are brought along
automatically. Again, dynamic classloading is appropriate here BECAUSE
jboss doesnt know what classes it will be dealing with.
-----Original Message-----
From: Tom Cook [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 15, 2001 5: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]
