You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by Andrew McCulloch <am...@gmail.com> on 2006/07/14 22:41:07 UTC
EJBControl for EJB 3.0
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.
5. Prototype a new Session Bean Control
6. Prototype a new Entity Bean Control
...
I am not as familiar with the persistence portion of the as with the portion
defining the Session and Message-Driven interfaces so I am not sure the
scope of changes that may be required around the Entity Bean Control and
EJB-QL changes specifically.
Also, I am not sure as to the current Geronimo support for EJB 3. I believe
this is where the current EJBControl drts run, if that support is
unavailable I may have to test against another container.
Re: EJBControl for EJB 3.0
Posted by Andrew McCulloch <am...@gmail.com>.
OK, these are great points that lead me to believe that and EJB3 control
does not provide much value add for Beehive right now. I will still do some
testing to make sure the current control works with EJB3 beans that use the
2.1 back compat annotations.
A generic injection method for pageflows that can inject EJBs as well as
Controls and other arbitrary objects seems like the way to go from here and
would provide far more benefit than an EJB3 control. It seems as if it
would not be possible to use the JSR-220 @EJB annotation based on Ken's
comment about cherry-picking JSR parts. As far as JSR-250... would it be
possible to implement all 10 annotations in Beehive?
@Generated seems like mostly a no-op, except perhaps using it in any
code-generated files Beehive apt processors create.
@Resource(s) seems like exactly what we are discussing
The 2 lifecycle based annotations appear to have some overlap with existing
lifecycle events that Beehive Controls already deal with.
The 5 security annotations are a bigger question since I am not familiar
with what beehive controls currently do around security. This may be a lot
of work that would preclude Beehive from implementing JSR-250... I just
don't know.
Maybe this is a much bigger wish-list than is necessary, but, I would hate
to have to invent/learn another set of dependency injection annotations if
there is any way we can use the ones that are already defined.
--Andrew
On 7/19/06, Eddie O'Neil <ek...@gmail.com> wrote:
>
> Ken--
>
> To your point on injection into JPF, I totally agree with the
> direction here. It should be possible (and super simple!) to inject
> arbitrary objects into a Page Flow and any other Beehive source
> artifact without limiting the framework to a specific type that can be
> injected. Basically, this should be a plug point that could be
> extended by a developer to implement arbitrary injection mechanisms
> (including support for @EJB). It'd be even better if there was a
> common way to specify an injection style between Controls, Page Flow,
> and web services so there's only one configuration point to learn.
>
> In general I agree that we could deprecate @Control in favor of
> other resource injection mechanisms as long as we're not tied to only
> injecting JNDI resources and private field injection is supported.
> Both of these have important uses that should come forward.
>
> Eddie
>
>
> On 7/19/06, Ken Tam <ke...@gmail.com> wrote:
> > IANAEE5E (I am not an EE5 expert :) either, but let's keep talking and
> > maybe we'll stumble our way to something useful..
> >
> > Agree that the web container supports @EJB for injection of an EJB3
> > client proxy -- I can't find it in the official specs, but I've seen a
> > Sun demo that did this. Yes, we'd definitely need to do some work to
> > support @EJB in pageflows, but in general it seems like it'd be a
> > great idea to move pageflow towards supporting various injection
> > mechanisms.
> >
> > (There may be some legal issues around supporting @EJB -- I'm thinking
> > of the prohibition on "cherry-picking" parts of a JSR, ie implementing
> > parts you like but not others -- but that seems like it would be
> > terribly stupid..)
> >
> > On 7/19/06, Chris Hogue <cs...@gmail.com> wrote:
> > > 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?
> >
> > I'm a little lost when it comes to references like "Andrew's second
> > case" -- not sure exactly what you're asking/saying here, but I'll
> > take a stab :)
> >
> > Per my earlier mails on future directions, I really believe controls
> > (and Beehive as a whole, including pageflows and wsm) ought to get out
> > of the injection business. E.g. we should deprecate @Control (though
> > still provide legacy support for it, outside of core), and support
> > injection via standard Javabean accessors, JSR-250, and other
> > standardized/popular mechanisms.
> >
> > Part of where controls add value is in its ability to define injected
> > values via annotations (that's what propertysets are all about) -- I
> > think we should continue to emphasize that, but treat annotations it
> > as yet another source of injection values, not as the way to define
> > what is injectable (a trail well-blazed already by others). Some of
> > the code in the hornet sandbox illustrates what that might look like.
> >
> >
> >
> > >
> > >
> > > -Chris
> > >
> > >
> > >
> > > On 7/18/06, Andrew McCulloch <am...@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 <ke...@gmail.com> wrote:
> > > > >
> > > > > Hi Andrew,
> > > > >
> > > > > On 7/14/06, Andrew McCulloch <am...@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.0client
> > > > > > 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.1remote/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)...
> > > > >
> > > >
> > > >
> > >
> >
>
Re: EJBControl for EJB 3.0
Posted by Eddie O'Neil <ek...@gmail.com>.
Ken--
To your point on injection into JPF, I totally agree with the
direction here. It should be possible (and super simple!) to inject
arbitrary objects into a Page Flow and any other Beehive source
artifact without limiting the framework to a specific type that can be
injected. Basically, this should be a plug point that could be
extended by a developer to implement arbitrary injection mechanisms
(including support for @EJB). It'd be even better if there was a
common way to specify an injection style between Controls, Page Flow,
and web services so there's only one configuration point to learn.
In general I agree that we could deprecate @Control in favor of
other resource injection mechanisms as long as we're not tied to only
injecting JNDI resources and private field injection is supported.
Both of these have important uses that should come forward.
Eddie
On 7/19/06, Ken Tam <ke...@gmail.com> wrote:
> IANAEE5E (I am not an EE5 expert :) either, but let's keep talking and
> maybe we'll stumble our way to something useful..
>
> Agree that the web container supports @EJB for injection of an EJB3
> client proxy -- I can't find it in the official specs, but I've seen a
> Sun demo that did this. Yes, we'd definitely need to do some work to
> support @EJB in pageflows, but in general it seems like it'd be a
> great idea to move pageflow towards supporting various injection
> mechanisms.
>
> (There may be some legal issues around supporting @EJB -- I'm thinking
> of the prohibition on "cherry-picking" parts of a JSR, ie implementing
> parts you like but not others -- but that seems like it would be
> terribly stupid..)
>
> On 7/19/06, Chris Hogue <cs...@gmail.com> wrote:
> > 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?
>
> I'm a little lost when it comes to references like "Andrew's second
> case" -- not sure exactly what you're asking/saying here, but I'll
> take a stab :)
>
> Per my earlier mails on future directions, I really believe controls
> (and Beehive as a whole, including pageflows and wsm) ought to get out
> of the injection business. E.g. we should deprecate @Control (though
> still provide legacy support for it, outside of core), and support
> injection via standard Javabean accessors, JSR-250, and other
> standardized/popular mechanisms.
>
> Part of where controls add value is in its ability to define injected
> values via annotations (that's what propertysets are all about) -- I
> think we should continue to emphasize that, but treat annotations it
> as yet another source of injection values, not as the way to define
> what is injectable (a trail well-blazed already by others). Some of
> the code in the hornet sandbox illustrates what that might look like.
>
>
>
> >
> >
> > -Chris
> >
> >
> >
> > On 7/18/06, Andrew McCulloch <am...@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 <ke...@gmail.com> wrote:
> > > >
> > > > Hi Andrew,
> > > >
> > > > On 7/14/06, Andrew McCulloch <am...@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)...
> > > >
> > >
> > >
> >
>
Re: EJBControl for EJB 3.0
Posted by Ken Tam <ke...@gmail.com>.
IANAEE5E (I am not an EE5 expert :) either, but let's keep talking and
maybe we'll stumble our way to something useful..
Agree that the web container supports @EJB for injection of an EJB3
client proxy -- I can't find it in the official specs, but I've seen a
Sun demo that did this. Yes, we'd definitely need to do some work to
support @EJB in pageflows, but in general it seems like it'd be a
great idea to move pageflow towards supporting various injection
mechanisms.
(There may be some legal issues around supporting @EJB -- I'm thinking
of the prohibition on "cherry-picking" parts of a JSR, ie implementing
parts you like but not others -- but that seems like it would be
terribly stupid..)
On 7/19/06, Chris Hogue <cs...@gmail.com> wrote:
> 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?
I'm a little lost when it comes to references like "Andrew's second
case" -- not sure exactly what you're asking/saying here, but I'll
take a stab :)
Per my earlier mails on future directions, I really believe controls
(and Beehive as a whole, including pageflows and wsm) ought to get out
of the injection business. E.g. we should deprecate @Control (though
still provide legacy support for it, outside of core), and support
injection via standard Javabean accessors, JSR-250, and other
standardized/popular mechanisms.
Part of where controls add value is in its ability to define injected
values via annotations (that's what propertysets are all about) -- I
think we should continue to emphasize that, but treat annotations it
as yet another source of injection values, not as the way to define
what is injectable (a trail well-blazed already by others). Some of
the code in the hornet sandbox illustrates what that might look like.
>
>
> -Chris
>
>
>
> On 7/18/06, Andrew McCulloch <am...@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 <ke...@gmail.com> wrote:
> > >
> > > Hi Andrew,
> > >
> > > On 7/14/06, Andrew McCulloch <am...@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)...
> > >
> >
> >
>
Re: EJBControl for EJB 3.0
Posted by Chris Hogue <cs...@gmail.com>.
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 <am...@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 <ke...@gmail.com> wrote:
> >
> > Hi Andrew,
> >
> > On 7/14/06, Andrew McCulloch <am...@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)...
> >
>
>
Re: EJBControl for EJB 3.0
Posted by Andrew McCulloch <am...@gmail.com>.
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 <ke...@gmail.com> wrote:
>
> Hi Andrew,
>
> On 7/14/06, Andrew McCulloch <am...@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)...
>
Re: EJBControl for EJB 3.0
Posted by Kenneth Tam <ke...@gmail.com>.
Hi Andrew,
On 7/14/06, Andrew McCulloch <am...@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)...
Re: EJBControl for EJB 3.0
Posted by Chad Schoettger <ch...@gmail.com>.
Hi Andrew,
I think your current plan sounds fine.
I don't think Geronimo has implemented EJB 3 support yet. I have
heard that JBoss claims to have support for EBJ 3, but haven't really
looked at it yet to see how complete it is.
The EJB control's DRTs do use Geronimo, so there may be a bit of work
necessary to get them up an running with some other application
server.
Try to keep the dev list updated with the results of your
investigation, right now I think a lot of devs are still spinning up
on the EJB 3.0 spec so you may not get lots of feedback at least
initially.
- Chad
On 7/14/06, Andrew McCulloch <am...@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.
> 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.
> 5. Prototype a new Session Bean Control
> 6. Prototype a new Entity Bean Control
> ...
>
> I am not as familiar with the persistence portion of the as with the portion
> defining the Session and Message-Driven interfaces so I am not sure the
> scope of changes that may be required around the Entity Bean Control and
> EJB-QL changes specifically.
>
> Also, I am not sure as to the current Geronimo support for EJB 3. I believe
> this is where the current EJBControl drts run, if that support is
> unavailable I may have to test against another container.
>
>