Hi James, The problem in the current state of Remoting is that org.jboss.remoting.AbstractInvoker, the grandparent of all invokers, client and server, starts by creating an org.jboss.remoting.loading.ClassByteClassLoader, which can load a class locally or, if it's not available locally, load it over the network. I'm thinking that the line | this.classbyteloader = new ClassByteClassLoader(this.getClass().getClassLoader()); | in AbstractInvoker could be replaced by | this.classbyteloader = getClass().getClassLoader(); | [In reality, of course, we would want the classloader to be configurable.] I've run this by a resident classloader expert who thought it sounded plausible. Now, for me, the problem is that I don't see a big demand for something like this, so, if there are some hidden gotcha's, I probably wouldn't put much time into it. On the other hand, if you experiment with the issue and get it to work, we could look at making the necessary changes to Remoting. It would be easy to make the classloader a configurable parameter, for example. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051568#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...