RMI Classloading problem.... help appreciated.
I've run into a RMI classloading problem that I don't know how to solve and I'm hoping someone has a suggestion about how to proceed. In this scenario there are 3 jvms: A. gshell B. a controller server C. a cluster node. In B, there are 2 classloaders of interest: j2ee-security and plugin- farm. The class I'm having trouble with is DownloadResults, which is available in plugin-farm but not j2ee-security. On B, there's a gbean, FarmGBean, in plugin-farm that calls the PluginInstallerGBean on C and gets a DownloadResults back. This call is over jmx using rmi. This call is made under two circumstances: 1. FarmGBean on B recieves a multicast packet from C and calls back to C, and successfully gets the DownloadResults back. I'm assuming that rmi is using the plugin-farm classloader here for the ObjectInputStream but haven't figure out how to check. 2. Gshell on A can call over jmx/rmi to the FarmGBean on B resulting in a call to C. In this case DownloadResults cannot be loaded: I get a message saying its not available in the j2ee-security classloader. (stack trace at end of email). I think that in (1) the thread that dispatches the call to C was started in code loaded in the plugin-farm classloader whereas in (2) the thread was started in the j2ee-server classloader. I'm not certain of this however. I've tried two things that haven't worked: a. setting the thread context classloader before the call to C to the plugin-farm classloader b. making the call to C a PrivilegedExceptionAction An idea I've had that I haven't tried yet because it seems rather complicated and seems like it might introduce security holes (at least it needs more thought) would be to modify the RMIClassLoaderSpiImpl. My idea is to represent geronimo classloaders with urls containing their artifactIds. The server would include this more or less fake url in the codebase for a class and the client would look for this special url to try to load the class with. Anyone know what osgi does for similar situations? Anyone have any suggestions? many thanks david jencks Here's the stack trace (on B): 12:22:05,777 WARN [FarmGBean] Error attempting to distribute plugin [EMAIL PROTECTED] to node 0.0.0.0:1109 java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.system.plugin.DownloadResults in classloader org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car (no security manager: RMI class loader disabled) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector $RemoteMBeanServerConnection.invoke(RMIConnector.java:972) at org .apache .geronimo.system.jmx.KernelDelegate.invokeKernel(KernelDelegate.java: 886) at org .apache.geronimo.system.jmx.KernelDelegate.invoke(KernelDelegate.java: 547) at org .apache .geronimo .kernel .basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) at org .apache .geronimo .system .jmx .JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:89) at org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$ $80823d3e.install(generated) at org.apache.geronimo.farm.plugin.FarmGBean.installToNode(FarmGBean.java: 223) at org .apache.geronimo.farm.plugin.FarmGBean.installToCluster(FarmGBean.java: 207) at org .apache .geronimo.farm.plugin.FarmGBean.installToClusters(FarmGBean.java:199) at org .apache .geronimo.farm.plugin.FarmGBean.addPluginToCluster(FarmGBean.java:193) at org .apache .geronimo.farm.plugin.FarmGBean.addPluginToCluster(FarmGBean.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at org .apache .geronimo .gbean .runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org .apache .geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org .apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java: 850) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java: 237) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 39) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at org .apache .geronimo .gbean
Re: RMI Classloading problem.... help appreciated.
David, No answers for you at this point, but I think the first thing I'd do is verify which thread context classloader is set in the case that's working. Perhaps the problem is not in setting the thread context loader, but rather getting it set to the correct one. Are the calls to C occurring in the same place in the FarmBean code? If not, are there any fundamental differences between the call environments? Rick David Jencks wrote: I've run into a RMI classloading problem that I don't know how to solve and I'm hoping someone has a suggestion about how to proceed. In this scenario there are 3 jvms: A. gshell B. a controller server C. a cluster node. In B, there are 2 classloaders of interest: j2ee-security and plugin-farm. The class I'm having trouble with is DownloadResults, which is available in plugin-farm but not j2ee-security. On B, there's a gbean, FarmGBean, in plugin-farm that calls the PluginInstallerGBean on C and gets a DownloadResults back. This call is over jmx using rmi. This call is made under two circumstances: 1. FarmGBean on B recieves a multicast packet from C and calls back to C, and successfully gets the DownloadResults back. I'm assuming that rmi is using the plugin-farm classloader here for the ObjectInputStream but haven't figure out how to check. 2. Gshell on A can call over jmx/rmi to the FarmGBean on B resulting in a call to C. In this case DownloadResults cannot be loaded: I get a message saying its not available in the j2ee-security classloader. (stack trace at end of email). I think that in (1) the thread that dispatches the call to C was started in code loaded in the plugin-farm classloader whereas in (2) the thread was started in the j2ee-server classloader. I'm not certain of this however. I've tried two things that haven't worked: a. setting the thread context classloader before the call to C to the plugin-farm classloader b. making the call to C a PrivilegedExceptionAction An idea I've had that I haven't tried yet because it seems rather complicated and seems like it might introduce security holes (at least it needs more thought) would be to modify the RMIClassLoaderSpiImpl. My idea is to represent geronimo classloaders with urls containing their artifactIds. The server would include this more or less fake url in the codebase for a class and the client would look for this special url to try to load the class with. Anyone know what osgi does for similar situations? Anyone have any suggestions? many thanks david jencks Here's the stack trace (on B): 12:22:05,777 WARN [FarmGBean] Error attempting to distribute plugin [EMAIL PROTECTED] to node 0.0.0.0:1109 java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.system.plugin.DownloadResults in classloader org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car (no security manager: RMI class loader disabled) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:972) at org.apache.geronimo.system.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:886) at org.apache.geronimo.system.jmx.KernelDelegate.invoke(KernelDelegate.java:547) at org.apache.geronimo.kernel.basic.KernelOperationInvoker.invoke(KernelOperationInvoker.java:46) at org.apache.geronimo.system.jmx.JMXProxyMethodInterceptor.intercept(JMXProxyMethodInterceptor.java:89) at org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$80823d3e.install(generated) at org.apache.geronimo.farm.plugin.FarmGBean.installToNode(FarmGBean.java:223) at org.apache.geronimo.farm.plugin.FarmGBean.installToCluster(FarmGBean.java:207) at org.apache.geronimo.farm.plugin.FarmGBean.installToClusters(FarmGBean.java:199) at org.apache.geronimo.farm.plugin.FarmGBean.addPluginToCluster(FarmGBean.java:193) at org.apache.geronimo.farm.plugin.FarmGBean.addPluginToCluster(FarmGBean.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237) at org.apache.geronimo.kernel.KernelGBean.invoke
Re: rmi classloading exceptions when launching 1.1
Shoot, I was hoping a stand-alone test case would fail as well, but it doesn't. :( So the issue is specific to invoking this within eclipse bundles. - sachin On Apr 25, 2006, at 11:17 PM, Sachin Patel wrote: I'm running into the following exception when launching 1.1 within eclipse and I can't figure out what is the root cause. The actual launch of the server is ok but the plugin code checks for when geronimo is fully started by checking the kernelFullyStarted attribute. I'm hitting the following set of exceptions below in my call to... AbstractNameQuery query = new AbstractNameQuery (PersistentConfigurationList.class.getName()); Set configLists = kernel.listGBeans(query); IIRC this is the same set of exceptions when people launched eclipse in a 1.5 JVM, however in this case I'm launching in 1.4 and I verified that the 1.0 support still works when calling the same code... I verified the G 1.1 jars I'm repackaging are the same as the ones inside the 1.1 image I'm launching but I'm hitting this now every single time. :( Does anyone have any ideas??? org.apache.geronimo.kernel.InternalKernelException: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at org.apache.geronimo.system.jmx.KernelDelegate.listGBeans (KernelDelegate.java:831) at org.apache.geronimo.st.v11.core.GeronimoServerBehaviour.isFullyStarted (GeronimoServerBehaviour.java:158) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:57) Caused by: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:169) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke (Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain (ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke (ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke (ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.system.jmx.KernelDelegate.invokeKernel (KernelDelegate.java:880) at org.apache.geronimo.system.jmx.KernelDelegate.listGBeans (KernelDelegate.java:827) ... 2 more Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java: 631) at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257) at sun.rmi.server.MarshalInputStream.resolveClass (MarshalInputStream.java:200) at java.io.ObjectInputStream.readNonProxyDesc (ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java: 1435) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at java.util.HashSet.readObject(HashSet.java:276) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeReadObject (ObjectStreamClass.java:838) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1746) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1646) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:297) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:146) ... 19 more
Re: rmi classloading exceptions when launching 1.1
Ok playing around I think I figured out the problem, but its going to be tricky getting a correct solution. The issue is the following... I'm supporting both V1 and V11 there are several jars at the same versions between 1.0 and 1.1 namely (mx4j, commons-logging, spec jars, etc..). Now I wanted to avoid repacking these jars multiple times so I pushed these into a common runtime plugin, where the V1 and V11 runtime bundles would depend on. The issue seems to be that the common plugin is where the de-serialization is happening and this bundle has no visibility to the class causing the CNF exception since the class is a V11 specific jar. As soon as I put a dependency on the V11 runtime bundle, the problem was resolved. However this (1) introduces a circular dependency between runtime.common and runtime.v11, and (2) Following the same pattern I would have to put a dependency on runtime.common to runtime.v1, which of course introduces the problem of multiple version of clasess in the same cp. So I'm going to play around with it some more but it may come down to that I am forced for at least a subset of the common jars to ship duplicates to get both V1 and V11 working and without introducing any circular dependencies or multiple versions of classes in the same bundle classpath. - sachin On Apr 26, 2006, at 8:31 AM, Sachin Patel wrote: Shoot, I was hoping a stand-alone test case would fail as well, but it doesn't. :( So the issue is specific to invoking this within eclipse bundles. - sachin On Apr 25, 2006, at 11:17 PM, Sachin Patel wrote: I'm running into the following exception when launching 1.1 within eclipse and I can't figure out what is the root cause. The actual launch of the server is ok but the plugin code checks for when geronimo is fully started by checking the kernelFullyStarted attribute. I'm hitting the following set of exceptions below in my call to... AbstractNameQuery query = new AbstractNameQuery (PersistentConfigurationList.class.getName()); Set configLists = kernel.listGBeans(query); IIRC this is the same set of exceptions when people launched eclipse in a 1.5 JVM, however in this case I'm launching in 1.4 and I verified that the 1.0 support still works when calling the same code... I verified the G 1.1 jars I'm repackaging are the same as the ones inside the 1.1 image I'm launching but I'm hitting this now every single time. :( Does anyone have any ideas??? org.apache.geronimo.kernel.InternalKernelException: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at org.apache.geronimo.system.jmx.KernelDelegate.listGBeans (KernelDelegate.java:831) at org.apache.geronimo.st.v11.core.GeronimoServerBehaviour.isFullyStarte d(GeronimoServerBehaviour.java:158) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:57) Caused by: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:169) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke (Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain (ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke (ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke (ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.system.jmx.KernelDelegate.invokeKernel (KernelDelegate.java:880) at org.apache.geronimo.system.jmx.KernelDelegate.listGBeans (KernelDelegate.java:827) ... 2 more Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165) at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java: 631) at
Re: rmi classloading exceptions when launching 1.1
At worst case adding duplicate jars with increase the size 1-1.5 megs. Thank you for listening to my conversation with myself :) - sachin On Apr 26, 2006, at 10:05 AM, Sachin Patel wrote: Ok playing around I think I figured out the problem, but its going to be tricky getting a correct solution. The issue is the following... I'm supporting both V1 and V11 there are several jars at the same versions between 1.0 and 1.1 namely (mx4j, commons-logging, spec jars, etc..). Now I wanted to avoid repacking these jars multiple times so I pushed these into a common runtime plugin, where the V1 and V11 runtime bundles would depend on. The issue seems to be that the common plugin is where the de-serialization is happening and this bundle has no visibility to the class causing the CNF exception since the class is a V11 specific jar. As soon as I put a dependency on the V11 runtime bundle, the problem was resolved. However this (1) introduces a circular dependency between runtime.common and runtime.v11, and (2) Following the same pattern I would have to put a dependency on runtime.common to runtime.v1, which of course introduces the problem of multiple version of clasess in the same cp. So I'm going to play around with it some more but it may come down to that I am forced for at least a subset of the common jars to ship duplicates to get both V1 and V11 working and without introducing any circular dependencies or multiple versions of classes in the same bundle classpath. - sachin On Apr 26, 2006, at 8:31 AM, Sachin Patel wrote: Shoot, I was hoping a stand-alone test case would fail as well, but it doesn't. :( So the issue is specific to invoking this within eclipse bundles. - sachin On Apr 25, 2006, at 11:17 PM, Sachin Patel wrote: I'm running into the following exception when launching 1.1 within eclipse and I can't figure out what is the root cause. The actual launch of the server is ok but the plugin code checks for when geronimo is fully started by checking the kernelFullyStarted attribute. I'm hitting the following set of exceptions below in my call to... AbstractNameQuery query = new AbstractNameQuery (PersistentConfigurationList.class.getName()); Set configLists = kernel.listGBeans(query); IIRC this is the same set of exceptions when people launched eclipse in a 1.5 JVM, however in this case I'm launching in 1.4 and I verified that the 1.0 support still works when calling the same code... I verified the G 1.1 jars I'm repackaging are the same as the ones inside the 1.1 image I'm launching but I'm hitting this now every single time. :( Does anyone have any ideas??? org.apache.geronimo.kernel.InternalKernelException: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at org.apache.geronimo.system.jmx.KernelDelegate.listGBeans (KernelDelegate.java:831) at org.apache.geronimo.st.v11.core.GeronimoServerBehaviour.isFullyStart ed(GeronimoServerBehaviour.java:158) at org.apache.geronimo.st.core.PingThread.run(PingThread.java:57) Caused by: java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:169) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke (Unknown Source) at mx4j.remote.rmi.ClientInvoker.invoke(ClientInvoker.java:207) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientUnmarshaller.chain (ClientUnmarshaller.java:65) at mx4j.remote.rmi.ClientUnmarshaller.invoke (ClientUnmarshaller.java:54) at $Proxy0.invoke(Unknown Source) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.ClientProxy.invoke(ClientProxy.java:32) at mx4j.remote.rmi.ClientExceptionCatcher.invoke (ClientExceptionCatcher.java:40) at $Proxy0.invoke(Unknown Source) at org.apache.geronimo.system.jmx.KernelDelegate.invokeKernel (KernelDelegate.java:880) at org.apache.geronimo.system.jmx.KernelDelegate.listGBeans (KernelDelegate.java:827) ... 2 more Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.gbean.AbstractName (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371) at
Re: RMI classloading
The nested exception case is interesting since there is value in recreating an exception on the client side. From what I recall, Corba does not have a standard way a sending back an arbitrary server exception to the client. As for remote interfaces, the client should already be able to access these. As for stubs, these can be auto generated and compiled on the client side or some form of proxying can be used to avoid stub generation. Stubs will implement the remote interface. I have seen other vendors either place server specific stubs into a client side jar or the client side name service could download them from an http server that is running within the app server. Mark Dain Sundstrom wrote: On Mar 17, 2005, at 6:06 PM, Alan D. Cabrera wrote: [EMAIL PROTECTED] wrote: Hi, I would like to know if it would be helpful to have a RMI class server. Currently, I see two potential usage: * deployment: currently, we need to be carefull about the exceptions nested within DeploymentException otherwise we will get a ClassNotFoundException. As a matter of fact, by installing a security manager and with the correct policy file, local deployments work properly. Indeed, as the ClassLoader used under the cover by Configuration is a URLClassLoader, marshalled classes are properly annotated. * IIOP: here I guess that we will need to download the stubs somehow to the clients. If you think that this is a good thing to have, then I am happy to get it working That sounds pretty cool. What do you think Mark? I think it would bee cool to have remote class loading, but I'm not sure about using the RMI wire protocol for this. I would expand the OpenEJB protocol to support remote class loading, and I believe IIOP has special hooks to do remote class loading javax.rmi.CORBA.Util, which in OpenEJB delegates to org.openejb.corba.util.UtilDelegateImpl. -dain .
Re: RMI classloading
On Mar 17, 2005, at 6:06 PM, Alan D. Cabrera wrote: [EMAIL PROTECTED] wrote: Hi, I would like to know if it would be helpful to have a RMI class server. Currently, I see two potential usage: * deployment: currently, we need to be carefull about the exceptions nested within DeploymentException otherwise we will get a ClassNotFoundException. As a matter of fact, by installing a security manager and with the correct policy file, local deployments work properly. Indeed, as the ClassLoader used under the cover by Configuration is a URLClassLoader, marshalled classes are properly annotated. * IIOP: here I guess that we will need to download the stubs somehow to the clients. If you think that this is a good thing to have, then I am happy to get it working That sounds pretty cool. What do you think Mark? I think it would bee cool to have remote class loading, but I'm not sure about using the RMI wire protocol for this. I would expand the OpenEJB protocol to support remote class loading, and I believe IIOP has special hooks to do remote class loading javax.rmi.CORBA.Util, which in OpenEJB delegates to org.openejb.corba.util.UtilDelegateImpl. -dain
Re: RMI classloading
Dain Sundstrom wrote: On Mar 18, 2005, at 2:42 PM, Jeremy Boynes wrote: Dain Sundstrom wrote: I think it would bee cool to have remote class loading, but I'm not sure about using the RMI wire protocol for this. I would expand the OpenEJB protocol to support remote class loading, and I believe IIOP has special hooks to do remote class loading javax.rmi.CORBA.Util, which in OpenEJB delegates to org.openejb.corba.util.UtilDelegateImpl. I think we should start with the most basic as RMI classloading is built into the VM and that is what we are using by default for JMX remoting. I think we should stop using RMI there also. RMI is the only JMX remoting protocol required by the spec - anything else is going to impose additional dependencies on anything that wants to talk to the server. We can obviously support additional protocols but we should continue to support the basics. -- Jeremy
Re: RMI classloading
Dain Sundstrom wrote: I think it would bee cool to have remote class loading, but I'm not sure about using the RMI wire protocol for this. I would expand the OpenEJB protocol to support remote class loading, and I believe IIOP has special hooks to do remote class loading javax.rmi.CORBA.Util, which in OpenEJB delegates to org.openejb.corba.util.UtilDelegateImpl. I think we should start with the most basic as RMI classloading is built into the VM and that is what we are using by default for JMX remoting. Everything else would add additional dependencies on the client. That's not to say we shouldn't add it to the other protocols, just that we need the lowest common denominator. -- Jeremy
RMI classloading
Hi, I would like to know if it would be helpful to have a RMI class server. Currently, I see two potential usage: * deployment: currently, we need to be carefull about the exceptions nested within DeploymentException otherwise we will get a ClassNotFoundException. As a matter of fact, by installing a security manager and with the correct policy file, local deployments work properly. Indeed, as the ClassLoader used under the cover by Configuration is a URLClassLoader, marshalled classes are properly annotated. * IIOP: here I guess that we will need to download the stubs somehow to the clients. If you think that this is a good thing to have, then I am happy to get it working. Thanks, Gianny
Re: RMI classloading
[EMAIL PROTECTED] wrote: Hi, I would like to know if it would be helpful to have a RMI class server. Currently, I see two potential usage: * deployment: currently, we need to be carefull about the exceptions nested within DeploymentException otherwise we will get a ClassNotFoundException. As a matter of fact, by installing a security manager and with the correct policy file, local deployments work properly. Indeed, as the ClassLoader used under the cover by Configuration is a URLClassLoader, marshalled classes are properly annotated. * IIOP: here I guess that we will need to download the stubs somehow to the clients. If you think that this is a good thing to have, then I am happy to get it working That sounds pretty cool. What do you think Mark? Regards, Alan
RE: RMI classloading
Hi, Hi, I would like to know if it would be helpful to have a RMI class server. Currently, I see two potential usage: * deployment: currently, we need to be carefull about the exceptions nested within DeploymentException otherwise we will get a ClassNotFoundException. As a matter of fact, by installing a security manager and with the correct policy file, local deployments work properly. Indeed, as the ClassLoader used under the cover by Configuration is a URLClassLoader, marshalled classes are properly annotated. * IIOP: here I guess that we will need to download the stubs somehow to the clients. If you think that this is a good thing to have, then I am happy to get it working. Just some warning here: 1. beware of the fact that classes may be exploded from jars in directories and pick up the correct place, if explosion happens 2. the annotation can be incredibly long, especially compared with data sent across a remote call, thus slowing down everything a lot. I would let an option to not use annotation for best performance, or a use a tinyurl mechanism of some sort. All the rest is to get annotations right, which is non-trivial but interesting :) Have fun ! Regards, Simon
