Yes - each ejb-jar has it's own abstract schema (11.2.1)
Yep... I want to remove this restriction in 4.0, because it is simply lame. I'm not sure I will be able to remove it, but I would like to.
Won't this break the EJB component contract by coupling the implementations?
ejb-ref's can define relations between EJBs in different jars but they only use the EJB's public contract (the home/remote interfaces) to do it.
CMP relations might be doable, but EJB-QL would require knowledge of the internal implementations - for example, what the abstract schema is for the other EJB. The spec explicitly disallows queries across jars just to avoid this coupling.
It's not like a workaround doesn't exist - the two implementations could simply be re-packaged into one jar thereby acknowledging the coupling between them.
The fun thing to go with that would be a CMP implementation capable of associating EJBs with different resource managers, and a EJB-QL implementation smart enough to figure out the heterogenous queries.
I don't think this breaks component coupling contracts (which are not defined by the spec). We already create ears with ejb-jars that refer to each other with ejb links.
We could allow abstract schemas in JBossQL to use a more qualified name... say .<abstract-schema-name>
By resouce manager I assume you mean physical persistent store. A heterogenours query engine would be very difficult to implement. In 4.0 I plan on support mapping EJBs to multiple physical stores, but a query will still be bounded by a single store. I hope someone implements a in memory query engine. Once we have that we could look at a heterogenours query engine, but is would be a major project.