Hi Paul, I've been thinking about this issue some more. 1. Definitely, setting the unmarshaller instance variable (if there is to be such a thing) should have been synchronized. 2. I've been re-reading the documentation on the Application Server classloading structure, particularly sections "3.2.2.4. Inside the JBoss Class Loading Architecture" - http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/S... and "3.5.1. Deployers and ClassLoaders" - http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/S.... It seems to me that, in the usual case, having the same jar in two different ears shouldn't be a problem, since classloading for both ears would be delegated to the same parent classloader, which is, in fact, the same classloader that loads the Remoting classes. I say "the usual case" because it's possible to configure an ear to use its own classloader. Does your application do that? If not, I'm wondering if the problem can be fixed 1. with the synchronization block around the unmarshaller creation code, and 2. without eliminating the call to setUnMarshaller(unmarshaller). If you have a chance, could you try that? Meanwhile, I will try to get some insight from someone in the Application Server group. -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128152#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...