Can other Deployments in JBoss EAP 6.1 be used as CDI bean archives?

[jjfraney]

I know about this: https://access.redhat.com/site/solutions/203583 and can inject beans from another deployment with it.  This application's cdi beans injects components from the bean archive in another deployment using this entry in the MANIFEST.MF: "Dependencies: deployment.other-ear.ear.other-ejb.jar meta-inf"

Note: The solution pages also includes 'annotations' in the manifest entry.  I exclude it because it  causes a parse failure, probably due to absence of the jandex index, which is not needed if I don't need the performance at startup.  The solution page did not describe how to produce a jandex index or even that it is required.

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.

2) @EJB, without lookup, to inject an ejb defined in the other deployment, fails.

3) @EJB, with lookup on global namespace (java:global/.../..), gives an ejb proxy.  i.e., success, a subsequent call on the proxy is delegated to a transactional ejb.

4) The same rules apply to all injects, even those done be cdi beans in the other deployment.

The test for 'transactional' is done by injecting a TransactionSyncrhonizationRegistry.  If this is not resolved, the  call to the injected bean is not transactional.

The implication is the developer must know to avoid certain injection syntax if there is some chance the application is to be deployed a certain way.  For example, a developer working on cdi beans that are deployed in the other deployment must be aware of this configuration and be sure to use @EJB with lookup parameter, and NOT @EJB without lookup nor @Inject.

I'm wondering if this is intended because it seems like a problem.

John

[jaikiran]

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.

[jjfraney]

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.