All you need is your RMI bundle to track a ?Marshaller? interface which bundles, interested in having their services RMI'd, register an impl which handles the (un)marshalling. The services might have a property listing the types they handle, or maybe it's a method call to test for support...
- Ray On Wed, Feb 25, 2015 at 12:19 PM, Łukasz Dywicki <luk...@dywicki.pl> wrote: > 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 > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
