4 Replies Latest reply on Nov 29, 2005 5:05 AM by kabirkhan

    no security manager: RMI class loader disabled

    kimbaltrue

      At this point I'm simply trying to get a remote interface (any interface) from JNDI, but the lookup throws an exception (see below.)

      javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.ejb3.JBossProxy (no security manager: RMI class loader disabled)]

      I have a very simple stateless EJB 3.0 bean that at this stage should be unsecured. It has one injected resource of an EntityManager. The Bean seems to load, but when I look it up in the JNDI viewer I see the same message shown above.

      Is there some security setup that's required with EJB 3.0 beans that I'm missing?

      Here is the code that fails. It never gets to the 'if' statement.

      try
       {
       InitialContext ic = new InitialContext();
       assert ic != null;
       System.out.println("Obtained Context");
       String name = AccountantRemote.class.getName();
       Object obj = ic.lookup(name);
       if(obj == null)
       System.out.println("A null");
       }
       catch(Exception ex)
       {
       System.out.println(ex);
       }


      The EJB3.0 Bean has a local and remote interface similiar to the calculator example.


        • 1. Re: no security manager: RMI class loader disabled
          bill.burke

          your client does not have JBossProxy in its classpath.

          ejb3.deployer/jboss-ejb3.jar

          • 2. Re: no security manager: RMI class loader disabled
            kimbaltrue

            Unfortunatly now I'm back to this exception:

            Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/aspects/asynch/AsynchProvider
             at java.lang.Class.getDeclaredFields0(Native Method)
             at java.lang.Class.privateGetDeclaredFields(Unknown Source)
             at java.lang.Class.getDeclaredField(Unknown Source)
             at java.io.ObjectStreamClass.getDeclaredSUID(Unknown Source)
             at java.io.ObjectStreamClass.access$600(Unknown Source)
             at java.io.ObjectStreamClass$2.run(Unknown Source)
             at java.security.AccessController.doPrivileged(Native Method)
             at java.io.ObjectStreamClass.<init>(Unknown Source)
             at java.io.ObjectStreamClass.lookup(Unknown Source)
             at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
             at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
             at java.io.ObjectInputStream.readClassDesc(Unknown Source)
             at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
             at java.io.ObjectInputStream.readObject0(Unknown Source)
             at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
             at java.io.ObjectInputStream.readSerialData(Unknown Source)
             at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
             at java.io.ObjectInputStream.readObject0(Unknown Source)
             at java.io.ObjectInputStream.readObject(Unknown Source)
             at java.rmi.MarshalledObject.get(Unknown Source)
             at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
             at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)
             at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
             at javax.naming.InitialContext.lookup(Unknown Source)
             at org.ccf.Medici.client.AccountantFactory.main(AccountantFactory.java:105)




            Where is this class?

            • 3. Re: no security manager: RMI class loader disabled
              kimbaltrue

              Okay, I found it though it would be nice if they were all in one place.

              deploy/jboss-aop.deployer/jboss-aspect-library-jdk50.jar

              Apparently is required as well.

              • 4. Re: no security manager: RMI class loader disabled
                kabirkhan

                In the jboss 4.0.3 sp1, all the ejb 3 stuff needed by clients is in jboss/client/jbossall-client.jar. But since the release cycles of ejb3 are smaller than those of the app server, the classes in the client jar might not be up to date when you update the ejb3.deployer following a new release