Hi all,
I am working on partly automated migration of a WAS60 J2EE 1.4 EAR using EJB 2.1 to a WAS80 JEE 6 EAR using EJB 3. However, I currently have everything working fine the EJB2 style (ejb-jar.xml, RemoteExceptions...), but I want to migrate to EJB3 style anyway.
As a result, the EAR will have difficulties in using CDI throughout, because actually there are lots of "not yet managed" components, which are in turn reluctant to CDI. Especially struts 1.3 is a candidate for this, although the "struts di" project alleviates some pain on this topic, however not completely painless. ;-)
Thus I need to have the EJBs expose EJB2 as well as EJB3 style interfaces, which separate into "remote business interface" for EJB3 and "remote component interface" for EJB2.
An EJB3 "remote business interface" can be automatically derived (basically) from its EJB2 "remote component interface" ancestor by removing the "extends EJBObject" clause, removing "throws RemoteException" clauses and dropping some annotations into a copy of the source code file at the right places, but this means doubling the formal business API. Thats quite error-prone for manual maintainance.
Is there any way to syntactically "join" the EJB3 "remote business interface" and the EJB2 "remote component interface" for any given EJB, given that both interface should expose the same "API"?
If I simply try to let the EJB2 "remote component interface" extend the full blown EJB3 "remote business interface" and additionally extend EJBObject, then I expect a conflict on deployment / first invocation, because the inherited business method signatures from the EJB3 "remote business interface" do not state to throw RemoteException which in turn is required for an EJB2 "remote component interface" to be accepted.
Do you have some hint on how to overcome code duplication on this issue?