i posted this message back when the mailing lists were being used directly (as opposed to now where we primarily use the forums and just see the messages via the list).
maybe i should turn this into the base for a wiki faq page since this topic seems to be coming up a lot as of late.
if you want to have two scoped ears in the same VM communicate w/ each other, then you need to extract the common interfaces out of both of the scoped ears and either deploy them as standalone jars, or package them up into an *unscoped* ear.
A.ear is scoped and exposes it's interface via a class called Foo.
B.ear is scoped and needs to use interface Foo to access A.ear
remove class Foo from both A.ear and B.ear and either deploy it in a standalone jar and you'll be good to go. the "whiteboard" picture would look something like this:
A.ear (scoped) B.ear (scoped)
so when A.ear asks for interface Foo, it sees that it is not available via it's classloader and then asks for it from the top level class loader. the same thing occurs w/ B.ear - it can't find the class, and asks the top level loader, leaving both ears to get the same class loader definition.
this also now allows you to hot deploy A.ear and/or B.ear w/o having to restart jboss.
this mechanism also works if for hot deploying unscoped ears as well.
keep in mind that if your interfaces return an object of type Baz, that class will also have to be packaged inside the same jar that contains the ejb interfaces.
a slight con to this approach is that if any of the classes change inside the standalone jar file and you redeploy it, you will either have to restart the server or "touch" all the other deployment archives that rely upon that jar. the reason for this is that the ear's class loader will have a stale reference to classes in the jar.
Ok, thank you for your help.
Yes, it might be a good idea to post your explanation on the wiki.