A while ago I had similar issue as yours which was affecting our RMI-based integration. Since I didn't want to turn on JVM security and enable RMI class loader I did following: 1. embedded all RMI contract classes which could be possibly loaded via RMI 2. my RMI client was executed from servlet thread so I had to override thread context class loader for each invocation.
Best regards, Lukasz 2015-02-25 18:14 GMT+01:00 Endo Alejandro <alejandro.e...@grassvalley.com>: > Hello everyone > > We are having an issue where we have a class that is an entry point to RMI > (an rmi proxy). As such, it deserializes remote objects before passing them > to the appropriate entity. However, this generic “gate-keeper” is throwing > an ClassNotFoundException since it doesn’t have a wire for the class that > it is trying to deserialize > > *java.rmi.ServerException*: *RemoteException* occurred in server thread; > nested exception is: > *java.rmi.UnmarshalException*: error unmarshalling arguments; nested > exception is: > *java.lang.ClassNotFoundException*: com.foo.SupportedCommand > at sun.rmi.server.UnicastServerRef.dispatch(*UnicastServerRef.java:354*) > at sun.rmi.transport.Transport$1.run(*Transport.java:178*) > at sun.rmi.transport.Transport$1.run(*Transport.java:175*) > at java.security.AccessController.doPrivileged(*Native Method*) > at sun.rmi.transport.Transport.serviceCall(*Transport.java:174*) > at sun.rmi.transport.tcp.TCPTransport.handleMessages( > *TCPTransport.java:557*) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0( > *TCPTransport.java:812*) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( > *TCPTransport.java:671*) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > *ThreadPoolExecutor.java:1142*) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > *ThreadPoolExecutor.java:617*) > at java.lang.Thread.run(*Thread.java:745*) > at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer( > *StreamRemoteCall.java:276*) > at sun.rmi.transport.StreamRemoteCall.executeCall( > *StreamRemoteCall.java:253*) > at sun.rmi.server.UnicastRef.invoke(*UnicastRef.java:162*) > at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod( > *RemoteObjectInvocationHandler.java:194*) > at java.rmi.server.RemoteObjectInvocationHandler.invoke( > *RemoteObjectInvocationHandler.java:148*) > at com.sun.proxy.$Proxy1.setParameter(Unknown Source) > at com.foo.proxy.GenericProxy.setParameter > at com.foo.proxy.AlarmManager$3.setParameter > at com.foo.proxy.AlarmManager$3.run > at com.foo.ThreadPool$PooledThread.run > Caused by: *java.rmi.UnmarshalException*: error unmarshalling arguments; > nested exception is: > *java.lang.ClassNotFoundException*: com.foo.SupportedCommand > at sun.rmi.server.UnicastServerRef.dispatch(*UnicastServerRef.java:314*) > at sun.rmi.transport.Transport$1.run(*Transport.java:178*) > at sun.rmi.transport.Transport$1.run(*Transport.java:175*) > at java.security.AccessController.doPrivileged(*Native Method*) > at sun.rmi.transport.Transport.serviceCall(*Transport.java:174*) > at sun.rmi.transport.tcp.TCPTransport.handleMessages( > *TCPTransport.java:557*) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0( > *TCPTransport.java:812*) > at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run( > *TCPTransport.java:671*) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > *ThreadPoolExecutor.java:1142*) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > *ThreadPoolExecutor.java:617*) > at java.lang.Thread.run(*Thread.java:745*) > Caused by: *java.lang.ClassNotFoundException*: com.foo.SupportedCommand > at java.net.URLClassLoader$1.run(*URLClassLoader.java:372*) > at java.net.URLClassLoader$1.run(*URLClassLoader.java:361*) > at java.security.AccessController.doPrivileged(*Native Method*) > at java.net.URLClassLoader.findClass(*URLClassLoader.java:360*) > at java.lang.ClassLoader.loadClass(*ClassLoader.java:424*) > at java.lang.ClassLoader.loadClass(*ClassLoader.java:357*) > at java.lang.Class.forName0(*Native Method*) > at java.lang.Class.forName(*Class.java:340*) > at com.foo.rmi.LoaderHandler.loadClass > at com.foo.rmi.LoaderHandler.loadClass > at com.foo.rmi.ClassLoaderProvider.loadClass > at java.rmi.server.RMIClassLoader.loadClass(*RMIClassLoader.java:264*) > at sun.rmi.server.MarshalInputStream.resolveClass( > *MarshalInputStream.java:214*) > at java.io.ObjectInputStream.readNonProxyDesc( > *ObjectInputStream.java:1613*) > at java.io.ObjectInputStream.readClassDesc(*ObjectInputStream.java:1518*) > at java.io.ObjectInputStream.readOrdinaryObject( > *ObjectInputStream.java:1774*) > at java.io.ObjectInputStream.readObject0(*ObjectInputStream.java:1351*) > at java.io.ObjectInputStream.readObject(*ObjectInputStream.java:371*) > at sun.rmi.server.UnicastRef.unmarshalValue(*UnicastRef.java:326*) > at sun.rmi.server.UnicastServerRef.dispatch(*UnicastServerRef.java:308*) > ... 10 more > > We hacked it by adding an explicit import-package in the bundle of the > proxy to com.foo since it is the package that contains SupportedCommand; it > works, but maintaining an explicit list of import-packages is always a > red-flag to me since it seems error-prone and a pain to maintain in the > long run. So I’m wondering what is the clean way to do this. It seems that > the model of static import-package doesn’t work well in such a bundle (i.e. > the bundle that contains and RMI proxy which should be allowed to know any > class that might come via RMI), is this a justified case for a > dynamicImport-package or is there a better idiom for these cases?? > > > > I would appreciate any thoughts on this, how have others solved this > issue? > > > > Thank you, > > > > Alejandro > > > > DISCLAIMER: Privileged and/or Confidential information may be contained in > this message. If you are not the addressee of this message, you may not > copy, use or deliver this message to anyone. In such event, you should > destroy the message and kindly notify the sender by reply e-mail. It is > understood that opinions or conclusions that do not relate to the official > business of the company are neither given nor endorsed by the company. > Thank You. > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
