8 Replies Latest reply on Aug 1, 2008 7:04 PM by wolfc

    CNFE when using PojiProxy/Remoting

    alrubinger

      In integrating EJB3 Proxy w/ EJB3 Core I'm occasionally coming across a CNFE when making a remote invocation from the client to the Container.

      // Create a POJI Proxy to the Container
       Interceptor[] interceptors =
       {IsLocalProxyFactoryInterceptor.singleton, InvokeRemoteInterceptor.singleton};
       PojiProxy handler = new PojiProxy(this.getContainerName(), locator, interceptors);
       Class<?>[] interfaces = new Class<?>[]
       {InvokableContext.class};
       InvokableContext<? extends ContainerMethodInvocation> container = (InvokableContext<?>) Proxy.newProxyInstance(
       interfaces[0].getClassLoader(), interfaces, handler);
      ...
      
       // Invoke
       Object result = container.invoke(proxy, invokedMethod, args);
      


      Exception received is below. What do I need to do to get the RMI CL enabled, manually put a security manager in place?

      Caused by: java.lang.ClassNotFoundException: com.sun.ts.tests.ejb30.sec.stateful.common.lTest (no security manager: RMI class loader disabled)
       at sun.rmi.server.LoaderHandler.loadProxyClass(LoaderHandler.java:531)
       at java.rmi.server.RMIClassLoader$2.loadProxyClass(RMIClassLoader.java:628)
       at org.jboss.system.JBossRMIClassLoader.loadProxyClass(JBossRMIClassLoader.java:82)
       at java.rmi.server.RMIClassLoader.loadProxyClass(RMIClassLoader.java:294)
       at sun.rmi.server.MarshalInputStream.resolveProxyClass(MarshalInputStream.java:238)
       at java.io.ObjectInputStream.readProxyDesc(ObjectInputStream.java:1500)
       at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1463)
       at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
       at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
       at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1634)
       at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
       at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
       at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
       at org.jboss.aop.joinpoint.MethodInvocation.getArguments(MethodInvocation.java:309)
       at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:118)
       at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
       at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:847)
       at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:681)
       at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:634)
       at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:459)
       at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:197)
       at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:203)
       at org.jboss.remoting.Client.invoke(Client.java:1685)
       at org.jboss.remoting.Client.invoke(Client.java:589)
       at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       at org.jboss.ejb3.proxy.remoting.IsLocalProxyFactoryInterceptor.invoke(IsLocalProxyFactoryInterceptor.java:72)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:61)
       at $Proxy3.invoke(Unknown Source)
       at org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:121)


      S,
      ALR



        • 1. Re: CNFE when using PojiProxy/Remoting
          alrubinger

          Oddly this is thrown from the server VM, not the client, at:

          07-24-2008 21:10:04: ERROR: java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.ts.tests.ejb30.sec.stateful.common.lTest (no security manager: RMI class loader disabled)
           at org.jboss.aop.joinpoint.MethodInvocation.getArguments(MethodInvocation.java:318)
           at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:118)
           at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
           at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:847)
           at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:681)
           at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:634)
           at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:459)
           at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:197)


          S,
          ALR

          • 2. Re: CNFE when using PojiProxy/Remoting
            anil.saldhana

            Something to do with classes and jar packaging. The interface is not available that RMI is trying to download.

            • 3. Re: CNFE when using PojiProxy/Remoting
              alrubinger

              I'm glad you replied, Anil, because this issue is regressing every single last one of the security tests for EJB3. :)

              What I don't understand is why EJB3 Proxy replacing the old mechanism would cause this to fail.

              S,
              ALR

              • 5. Re: CNFE when using PojiProxy/Remoting

                As I said on the call, the problem is the TCL not getting set properly.
                When you invoke on the EJB Container it overrides the dynamicInvoke
                to do this, e.g. StatefulContainer

                 public InvocationResponse dynamicInvoke(Object target, Invocation invocation) throws Throwable
                 {
                 long start = System.currentTimeMillis();
                
                 ClassLoader oldLoader = Thread.currentThread().getContextClassLoader();
                 EJBContainerInvocation newSi = null;
                 pushEnc();
                 try
                 {
                 Thread.currentThread().setContextClassLoader(classloader);
                
                // etc.
                


                • 6. Re: CNFE when using PojiProxy/Remoting
                  alrubinger

                  I'd only set the TCL on Container.invoke(), so will look at dynamicInvoke as soon as I get a clean workspace.

                  Thanks again to all for looking earlier.

                  S,
                  ALR

                  • 7. Re: CNFE when using PojiProxy/Remoting
                    alrubinger

                    dynamicInvoke had the proper TCL set, problem is nothing was running through it because I'd removed registration of the Container with AOP via the ClassProxyHack:

                    - Dispatcher.singleton.registerTarget(getObjectName().getCanonicalName(), new ClassProxyHack(this));
                    + Dispatcher.singleton.registerTarget(getObjectName().getCanonicalName(), this);


                    Where the ClassProxyHack has:

                    public InvocationResponse _dynamicInvoke(Invocation invocation) throws Throwable
                     {
                     return container.dynamicInvoke(null, invocation);
                     }


                    ...and this is what gives me my hook to set the proper TCL.

                    From here I've got the hooks I need to resolve this.

                    S,
                    ALR

                    • 8. Re: CNFE when using PojiProxy/Remoting
                      wolfc

                      Dispatcher:118 is a piece of code where it makes a final attempt to invoke the method, so it tries it by itself. This is bound to fail, because Dispatcher has no knowledge of the right class loader context, only the EJB container knows this.

                      ClassProxyHack came into being because EJBContainer used to be an AOP ClassContainer and thus it remoted it's governing class (/bean class) and not itself. The current EJBContainer still has that same remoting characteristic.