Christian Gosch

Greenhorn
+ Follow
since May 15, 2013
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian Gosch

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.
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?
Look at the quote below, comments on EntityManager declarations are added by me:

Piotr Nowicki wrote:





I wonder if the "concrete EM" declared in ConcreteServiceBean is necessary!

What happens if no EM is declared in ConcreteServiceBean ? The EM declared in GenericCrudBean should be visible also here?

Thanks for useful answers (because this "architecture" fully matches what I am doing also :-) )
Sorry if this has been posted already, but a quick first-50 headline scan did not reveal any similar post:

I think the topic content area is too narrow because medium-to-long sample code lines are wrapped now which is realy ugly to read. (They are not "auto-indented" although the display component seems to be aware of basic language syntax.)

Thats it. Not all new stuff is nice also :-(
10 years ago