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?
Joined: May 15, 2013
In fact I ended up in "copying & modifying" the EJB2-style remote COMPONENT interface into a modified form, being a valid EJB3-style remote BUSINESS interface.
The EJB3 RBI variant looks very similar to the EJB2 RCI, but all "throws RemoteException" are removed etc. To do this automatically you will need a Java source parser, which additionally should be able to climb up the inheritance hierarchy of the original EJB2 RCI to "copy & modify" all interfaces which the RCI does extend (and which are part of your project's source tree).
After having done this you also can automatically "decorate" the bean implementation classes (BIC) to get a mixed bean implementation which is valid for both "EJB2-style" and "EJB3-style" usage inside a JEE6 EJB3 container.
Finally you will end up in having unchanged EJB2 RCI+RHI, modified EJB2+EJB3 BIC, and new EJB3 RBI (based on the EJB2 RCI) for all EJBs you process. Since you might have many client calls from different JEE layers (other EJB: Simple; WAR: Maybe simple; static blocks: Some rework necessary; schedulers: Watch out for JNDI lookup problems when using Quartz!) for your EJBs, you probably will not be able to kick away the EJB2 RCI+RHI and descriptors immediately, but maybe you must stick to them for a while.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com