I'm doing similar thing to download home and remote
interfaces for my beans from the server. It works.
But, I'm using regular SecurityManager instead of
RMISecurityManager and I have all jboss-client jars
and jndi.properties in the client classpath.
It worked on cvs snapshot from 11/7. Client behavior
haven't dependent of number of runs.
If you can send me your hack to WebServer, I'll check
the situation more precisely.
[EMAIL PROTECTED] wrote:
>
> 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]> To: jBoss
> <[EMAIL PROTECTED]>
> 11/08/2000 10:27 AM cc:
> Please respond to jBoss 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]
--
_________________________________________________________
Alexander Kogan Parametric Technology Corporation
[EMAIL PROTECTED] 128 Technology Drive, Waltham MA 02453
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
