beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Hogue" <csho...@gmail.com>
Subject Re: EJBControl for EJB 3.0
Date Wed, 19 Jul 2006 22:26:16 GMT
I was wondering about Andrew's second case. I'm not an expert on the
EE5 spec but I believe it does support injection into different
containers, including the web container. Of course it knows nothing
about page flows. So for example, if I wanted to use an EJB3 SLSB from
a page flow, I assume I couldn't use @EJB injection to do that without
work in the page flow runtime.

So this may be what Andrew is implying, but is the second case really
about supporting @EJB injection (and possibly other JSR-250
annotations like @Resource) in page flows and controls?


-Chris



On 7/18/06, Andrew McCulloch <amccullo@gmail.com> wrote:
> Kenneth,
>
> Thanks for the input!  Yesterday when going through the possible use cases
> for this control I came to much the same thought...  What would be the value
> add for an EJBControl on top of EJB3 Session Beans?  Basically I have come
> up with a couple of minor points.  First is consistency.  Users who
> currently use controls for accessing almost every resources may want to
> continue that model with EJB3.   This is a very minor point and by itself
> may not warrant this development effort.  The second issue may just be a
> misunderstanding of the spec on my part, but, I will mention it anyway.
> Does the JEE 5 spec require the @EJB injection to work from every
> container?  If not, it may be worth having the control to hide the jndi
> lookup users would be required to do if they access an EJB from the web
> container.  This simply hides a few lines of code that could also be
> abstracted into helper classes by the user.  This would mean that #4 in my
> original e-mail may be moot.  So these two points by themselves are probably
> not worth creating a EJB3 control, but coupled with any work involving my
> first task below may make it a trivial amount of additional effort, I am not
> sure.  I also need to investigate further to see if there are any additional
> featured introduced in EJB3 that would be worth exposing in an EJBControl,
> perhaps surrounding transactions or security.
>
> As far as entity beans go...  I have not gotten to the point where I
> understand the changes from 2.1 to 3.0 enough to comment on any possible
> value add here.  I hope to get to a more knowledgeable point on the subject
> this week.
>
> Thanks,
> --Andrew
>
> On 7/18/06, Kenneth Tam <kentaminator@gmail.com> wrote:
> >
> > Hi Andrew,
> >
> > On 7/14/06, Andrew McCulloch <amccullo@gmail.com> 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.
> >
> > +1
> >
> > > 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 = trader.buy(stock, 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 = traderControl.buy(stock, shares);
> >      return  tradeResult;
> > }
> > catch (RemoteException re) {
> >      ...
> > }
> > finally {
> >     if (traderControl != null)
> >         traderControl.remove();
> > }
> >
> > EJB 3:
> >
> > @EJB
> > Trader trader
> >
> > TradeResult tradeResult = trader.buy(stock, 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)...
> >
>
>

Mime
View raw message