EJBTHREE-786| JBoss.org Content Archive (Read Only)

15. Re: EJBTHREE-786

pmuir Oct 2, 2007 12:41 PM (in response to alrubinger)

So, from the Seam perspective:

* very few users have EJB2 views and most are going to be using *just* EJB3

* making them put @JBossEJBStuff on every interface/class isn't very nice so I would like to avoid this if at all possible.

* We still have the corner case of a user wanting both EJB2 and to use the Seam framework (maybe this is something we document as just not working for now)

I have a feeling a global metadata with an annotation either way (@NoEjb2View, @Ejb2View) could work? What the default is I don't know. I would argue for NoEjb2View obviously, but I don't know if that works for the TCK (it sounds from Bill like it does).

16. Re: EJBTHREE-786

gavin.king Oct 2, 2007 12:50 PM (in response to alrubinger)

"bdecoste" wrote:
At the risk of oversimplifying, can we just make a remove() method on a business interface invalid? I think creating dual proxies gets too complicated and not being able to cast a proxy to EJBObject opens another can of worms

No we definitely cannot do this. The EJB3 spec places no such restriction upon a business interface. Doing this would mean that perfectly valid EJBs (that execute on other people's platforms) do not execute on JBoss.

17. Re: EJBTHREE-786

gavin.king Oct 2, 2007 12:52 PM (in response to alrubinger)

"bill.burke@jboss.com" wrote:
Unless there is a TCK test, do not take 4.7.1 literally. Seriously Carlo, you need to stop taking things literally and think what's best for the user and the design/maintenance of our code.

Absolutely. 4.7.1 should not be taken literally (it doesn't even make sense for EJB3 beans).

18. Re: EJBTHREE-786

gavin.king Oct 2, 2007 12:53 PM (in response to alrubinger)

"bill.burke@jboss.com" wrote:
I know the intention of the specification. We can challenge any TCK test based on knowledge of this intention. IIRC, the spec says *nothing* about requiring an EJB 3.0 reference to be castable or narrowable to EJBObject. This is just something *JBoss* threw in.

Correct, the spec does not require this. In fact, it says the exact opposite in section 3.4.

19. Re: EJBTHREE-786

gavin.king Oct 2, 2007 12:55 PM (in response to alrubinger)

Again, can't we just tell SEAM to change their method name and disallow EJBObject methods on Remote interfaces like EJB2.1 does?

Seam is not the only application in the universe that I could imagine defining a method named "remove".

20. Re: EJBTHREE-786

gavin.king Oct 2, 2007 1:02 PM (in response to alrubinger)

Keep implementation as it current stands, but add new metadata (ie. @NoEjb2View) which will designate that we shouldn't have EJBObject be implemented by the Proxy. Benefit here is that we keep support to EJB3.0 and EJB2.1 clients by default, and provide mechanism for Seam to have their "remove" method.

This is definitely not OK. It is an @ActuallyComplyWithTheEJBSpec annotation.

21. Re: EJBTHREE-786

alrubinger Oct 2, 2007 1:03 PM (in response to alrubinger)

"pete.muir@jboss.org" wrote:
So, from the Seam perspective:

* very few users have EJB2 views and most are going to be using *just* EJB3

* making them put @JBossEJBStuff on every interface/class isn't very nice so I would like to avoid this if at all possible.

I hear and agree with both of these points.

"pete.muir@jboss.org" wrote:

* We still have the corner case of a user wanting both EJB2 and to use the Seam framework (maybe this is something we document as just not working for now)

Carlo's double-proxy solution solves this, as does Bill B's suggestion to only have the proxy implement EJBObject if the interface itself extends EJBObject

"pete.muir@jboss.org" wrote:

I have a feeling a global metadata with an annotation either way (@NoEjb2View, @Ejb2View) could work? What the default is I don't know. I would argue for NoEjb2View obviously, but I don't know if that works for the TCK (it sounds from Bill like it does).

I like the ability to set global metadata for this property (unless overridden by annotation), though I think a default of NoEjb2View conflicts with Spec 3.6:

The remainder of this chapter describes the Session Bean client view defined by the EJB 2.1 and earlier specifications. Support for the definition and use of these earlier client interfaces is required to be provided by implementations of the EJB 3.0 specification.

...and is further defined in 3.6.4.

S,
ALR

22. Re: EJBTHREE-786

bdecoste Oct 2, 2007 1:10 PM (in response to alrubinger)

The suggestion to only have the proxy implement EJBObject if the Remote interface extends it is the only one that makes any sense. As I've said, if they want EJB2.1 clients they already have to create a home interface so it's not an inconvenience. And we can work through whatever TCK problems that may arise. I second the motion.

23. Re: EJBTHREE-786

wolfc Oct 2, 2007 1:19 PM (in response to alrubinger)

"gavin.king@jboss.com" wrote:
"bill.burke@jboss.com" wrote:
I know the intention of the specification. We can challenge any TCK test based on knowledge of this intention. IIRC, the spec says *nothing* about requiring an EJB 3.0 reference to be castable or narrowable to EJBObject. This is just something *JBoss* threw in.

Correct, the spec does not require this. In fact, it says the exact opposite in section 3.4.

Exactly and because we threw this in we get the remove signature problem.

How about we take out the explicit binding of EJBObject in the proxy factories. If one of the interfaces extends EJBObject it'll be picked up again.

The home interface will be bound to .../home anyway (or bound together if requested), which is always a EJB 2.1 home interface, so no clash there.

Only the EJB 2.1 home should return proxies which implement EJBObject. So .../remote and .../local should all be EJB 3 bindings.

Which leaves getInvokedBusinessInterface. I really would like to see it return the invoked business interface.

24. Re: EJBTHREE-786

wolfc Oct 2, 2007 1:46 PM (in response to alrubinger)

If a bean use the EJB 2.1 view it can't have a remove method with another signature, so no problem there.

25. Re: EJBTHREE-786

bdecoste Oct 2, 2007 3:38 PM (in response to alrubinger)

OK, after a lengthy discussion with Burke, Carlo, and Andrew here is the decision - we are going to remove the impls of EJBObject/EJBLocalObject by default. If a 2.1 view is required, the Remote/Local interfaces will need to explicitly extend EJBObject/EJBLocalObject. Then the proxy will implement those interfaces.

- This removes the restriction on remove() and other EJBObject methods
- This still provides availability of a full 2.1 view. Minimal inconvenience for the developer as they already have to provide a home interface that extends EJBHome.

26. Re: EJBTHREE-786

alrubinger Oct 2, 2007 3:57 PM (in response to alrubinger)

I will implement as detailed in the previous post tomrorrow.

S,
ALR

27. Re: EJBTHREE-786

alrubinger Oct 3, 2007 10:05 PM (in response to alrubinger)

Some progress made today and committed to trunk. EJBObject/EJBLocalObject now only implemented by Proxy if explicitly extended by bean provider's business interface.

In the case of "remove" methods, this is now permitted.

EJBObject/EJBLocalObject methods (ie. "remove" to remove a stateful instance), however, fail when cast from the Proxy to EJBObject/EJBLocalObject. To be revisited before completion of this task.

S,
ALR

28. Re: EJBTHREE-786

bdecoste Oct 4, 2007 7:32 PM (in response to alrubinger)

New issue has come up ...

If a bean's interface does NOT implement EJBObject, is SessionContext.getEJBObject() still valid? The proxy would not implement EJBObject, but should SessionContext still support it? I think it should.

29. Re: EJBTHREE-786

wolfc Oct 5, 2007 3:39 AM (in response to alrubinger)

SessionContext.getEJBObject should throw an IllegalStateException when the bean doesn't have a remote interface. (Similar for getEJBLocalObject.)

http://jira.jboss.com/jira/browse/EJBTHREE-1057