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...