Thank you Lukasz and Raymond. I will think about both solutions
From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Raymond Auge Sent: Wednesday, February 25, 2015 12:37 PM To: OSGi Developer Mail List Subject: Re: [osgi-dev] ClassNotFoundException with RMI 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<mailto: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<mailto: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<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto: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) 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
