Ok, so I'm a bit naive.... :)
Here's how i've hacked up my sample code:
import javax.naming.*;
import javax.rmi.PortableRemoteObject;
import java.rmi.RMISecurityManager;
import java.net.*;
import assetmgr.biz.*;
public class test {
public static void main(String[] args) {
try {
Thread.currentThread().setContextClassLoader(new URLClassLoader(new URL[] { new URL("http://localhost:8083/") }));
System.out.println("Set the classloader");
System.setSecurityManager(new RMISecurityManager());
System.out.println("Set the security manager");
Context ctx = new InitialContext();
System.out.println("Created a context");
Object ref = ctx.lookup("UserMgmt");
System.out.println("performed the lookup");
UserMgmtHome home = (UserMgmtHome)PortableRemoteObject.narrow(ref, UserMgmtHome.class);
System.out.println("narrowed the reference");
UserMgmt usermg = home.create();
System.out.println("created the bean instance");
System.out.println(usermg.getAllUsersHTML());
System.out.println("Got the user's html");
} catch (Exception e) {
System.out.println("Caught an exception: " + e);
e.printStackTrace();
}
}
}
I also added a line to the webserver so that it notifies the server console whenever it's going to transfer a file (and with the name of the file)
When I run my client like this:
java -Djava.security.policy=java.policy test (java.policy has AllPermission set)
The client fails with a "cannot instantiate class: org.jnp.interfaces.NamingContextFactory". The funny thing is, is that the server just transferred that file (I can see that via my webserver hack) Actually, the client must always be requesting jndi.properties, then the NamingContextFactory class (also via my webserver hack).
[Webserver] Going to transfer this path: jndi.properties
[Webserver] Going to transfer this path: org/jnp/interfaces/NamingContextFactory.class
SO--I conceded and included jnp-client.jar in my classpath, and run my client like this:
java -classpath $CLASSPATH:/opt/jboss/client/jnp-client.jar -Djava.security.policy=java.policy test
The client then hangs after setting the security manager (problem while trying to create the Context). The webserver shows that it transfers jndi.properties. (and that's all)
[Webserver] Going to transfer this path: jndi.properties
What's even weirder is that the system behaves differently after it is first started up, than after a few runs of this test. I start the server clean, and try the client, and the client complains about a NoClassDefFound for javax/ejb/EJBHome, right after this server output:
[Webserver] Going to transfer this path: jndi.properties
[Webserver] Going to transfer this path: assetmgr/biz/UserMgmtHome.class
[Webserver] Going to transfer this path: javax/ejb/EJBHome.class
And this time, the client was able to create a context before the exception is thrown.
Running the client again immediately with the same params, hangs the client right after it creates the context, with the webserver reporting that only jndi.properties was transferred.
Wow--that was really long-winded. I really appreciate your help on this. I had thought this should be possible, after reading this post by Rickard a long time ago -- http://www.mail-archive.com/[email protected]/msg00382.html .
-Jason
| Rickard �berg <[EMAIL PROTECTED]>
11/08/2000 10:27 AM
|
To: jBoss <[EMAIL PROTECTED]> cc: Subject: Re: [jBoss-User] DCL |
Hey
[EMAIL PROTECTED] wrote:
> <code>
> import javax.naming.*;
> import javax.rmi.PortableRemoteObject;
> import java.rmi.RMISecurityManager;
>
> import assetmgr.biz.*;
>
> public class test {
> public static void main(String[] args) {
> try {
> System.setSecurityManager(new RMISecurityManager());
> Context ctx = new InitialContext();
> Object ref = ctx.lookup("UserMgmt");
> UserMgmtHome home =
> (UserMgmtHome)PortableRemoteObject.narrow(ref, UserMgmtHome.class);
> UserMgmt usermg = home.create();
> System.out.println(usermg.getAllUsersHTML());
> } catch (Exception e) {
> System.out.println("Caught an exception: " + e);
> e.printStackTrace();
> }
> }
> }
> </code>
>
> Is it supposed to be that simple?
There's no policy file set above. Have you set that properly?
> Do I need to setup any special
> classloaders? Anyway here's the output:
>
> <output>
> Caught an exception: javax.naming.NoInitialContextException: Cannot
> instantiate class: org.jnp.interfaces.NamingContextFactory [Root
> exception is java.lang.ClassNotFoundException
> : org.jnp.interfaces.NamingContextFactory]
> javax.naming.NoInitialContextException: Cannot instantiate class:
> org.jnp.interfaces.NamingContextFactory. Root exception is
> java.lang.ClassNotFoundException: org.jnp.interfaces
> .NamingContextFactory
Have you included jnp-client.jar in your clients classpath?
In its basic form dynamic classloading only works for jboss-client.jar
and any EJB bean interfaces and classes. Due to the workings of JNDI DCL
does not work the way you have done it above. A workaround for this is
to use a Reference which points out the factory and codebase from where
the classes can be loaded. There are more detailed postings on this (by
me) in the archives for this list.
You can also set a URLClassLoader as context classloader for this to
work, which might be simpler:
Thread.currentThread().setContextClassLoader(new URLClassLoader(new
URL[] { new URL("http://localhost:8083/") }));
This will allow JNDI to find the JNP classes properly.
> (a jndi.properties file is in the classpath so the url to the server
> should be known
Yes, but not the JNDI implementation codebase.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
