atom feed8 messages in org.apache.beehive.devRe: EJBControl for EJB 3.0
FromSent OnAttachments
Andrew McCullochJul 14, 2006 1:40 pm 
Chad SchoettgerJul 18, 2006 8:26 am 
Kenneth TamJul 18, 2006 3:59 pm 
Andrew McCullochJul 18, 2006 7:47 pm 
Chris HogueJul 19, 2006 3:25 pm 
Ken TamJul 19, 2006 7:00 pm 
Eddie O'NeilJul 19, 2006 8:46 pm 
Andrew McCullochJul 20, 2006 9:09 am 
Subject:Re: EJBControl for EJB 3.0
From:Kenneth Tam (
Date:Jul 18, 2006 3:59:47 pm

Hi Andrew,

On 7/14/06, Andrew McCulloch <> wrote:

I have been reading up a bit on the EJB 3 spec and I would like to look into updating / cloning the current EJBControl to support the EJB 3.0 client contracts. I am looking for a few pointers on what features of the new spec the community might be most interested in (it may be too new for this feedback). I would also be receptive to any other thoughts on this topic that you may have.

My current plan: 1. Determine if the current controls works against EJB 3 beans that use the back-compat annotations in the spec to produce the remote interfaces and other EJB 2.1 artifacts.


2. Determine what would have to be modified on the Session Bean Control to use only the Business interface through direct lookups. 3. Determine what would have to be modified on the Entity Bean Control to use only EJB 3.0 artifacts through direct lookups. 4. Determine what would have to be modified on the 2 controls to make use of EJB Dependency Injection instead of direct lookups.

Can you describe a few use-cases for these items? I'm not very knowledgeable about EJB 3, but it seems to me that the EJB 3 client model has essentially standardized much of the value-add that the EJB control offered in terms of simplifying the EJB 2.1 client model, to the point where I don't really understand how what you're proposing would make life easier for the developer.

Take a classic session bean use-case:


EJB 2.1:

Trader trader = null; try { InitialContext ic = new InitialContext(); TraderHome home = (TraderHome)ic.lookup("MyTraderBean"); trader = home.create(); TradeResult tradeResult =, shares); return tradeResult; } catch (NamingException e) { ... } catch (CreateException e) { ... } catch (RemoteException e) { ... } finally { if (trader != null) trader.remove(); }

EJB Control:

@Control TraderControlBean traderControl;

try { TradeResult tradeResult =, shares); return tradeResult; } catch (RemoteException re) { ... } finally { if (traderControl != null) traderControl.remove(); }

EJB 3:

@EJB Trader trader

TradeResult tradeResult =, shares); return tradeResult;


Between what the spec has done in switching to an injection model, removing the need for a home interface (and corresponding indirection), and removing the need to support RemoteExceptions on the business interface, I'm at a bit of a loss to see where there's real value to be added in evolving the current EJB control to make it easier to work with EJB 3 beans.

My sense is that the value of the EJB control today is in providing EJB3-style ease-of-use on top of EJB 2.1 beans -- and actually, this is an area where EJB3 didn't really make huge inroads. Even though the EJB 3 client model supports accessing 2.1 beans, there is still value in what the EJB control does wrt collapsing the remote/local & home interfaces and managing some of the exceptions.

An ideal result would be the ability to treat an EJB 2.1 remote/local interface just like an EJB 3 business interface. Collapsing the remote/local & home interfaces is the easy part, but there's a tension between simplifying exception handling and ease of authoring.. since the remote interface will always throw RemoteException, it seems the only way to eliminate it would be to author a separate interface (which is a drag)...