Without looking at the code and related stacktraces, it's hard to say.
John Franey wrote:
The following is observed. Is this expected? or will a later release change this behavior?
1) @Inject an ejb from the other deployment gives a proxy that is not transactional. ie: a subsequent call on the proxy is not run within a transaction.
The test for 'transactional' is done by injecting a TransactionSyncrhonizationRegistry. If this is not resolved, the call to the injected bean is not transactional.
That's not really the right way to test if it's transactional or not. TransactionSyncrhonizationRegistry not being injected just means that it's not injected, which could be a bug, but that doesn't imply that the bean isn't running in a transaction. To really test that it's running in a transaction (it should be), do some transactional activity within that business method and see how it goes (write out to a DB and throw a system exception while returning from the method and check if it gets rolled back).
For that matter you could even lookup TransactionSynchronizationRegistry manually under java:comp/TransactionSynchronizationRegistry from the EJB method and check the status of the transaction. That's of course if you want to test that the method is transactional.
As for injection not working, please post the relevant code that illustrates that TransactionSynchronizationRegistry isn't injected.
Thanks. I was encouraged by your answer to expect number 1 to work (i.e., injecting an ejb from another deployment would maintain the ejb's transactional boundary. My test prototype no longer relies on injecting TransactionSynchronizationRegistry to test transactional status. As you suggested, I forced a failure and I see the transaction rollback in the stack trace: Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.