Perhaps this is a sign of a classloader leak? Proxy.getProxyClass(...) is maintaining a cache of proxy classes, keyed by a List of the interface names that define the class. Separate cache for each classloader. In this case the classloader is the default one used by the Remoting connector. I'm pretty sure we'll leak the proxy class (and thus its business interfaces) to that data structure. There are other tests that deploy the same jar, so this code will find a proxy class from an earlier deployment, but will then fail to find the constructor because the classes currently on the classpath are different. Seems like generating a Proxy class using something other than the container classloader is a classloader leak. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171813#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...