-
1. Re: EJBTHREE-786
There are a couple of things tied together:
- getInvokedBusinessInterface returns an interface based on method signature
- multiple local business interfaces doesn't work properly
- EJB 3 4.7.1: generated classes
- EJBTHREE-786: remove method
If we take 4.7.1 literaly then we must have a proxy class for each interface that the bean has. I don't know if TCK demands such a thing. But if we want to know for sure which interface was invoked we need to have different proxies and thus different bindings. This would also resolve EJBTHREE-786.
Note that in a lot of code the distinction between a local business interface and a local 2.1 interface isn't properly made.
The question is does it eliminate the possiblity for a combined binding (issue 540)?
Probably not, but it would make things more complicated. -
2. Re: EJBTHREE-786
We did it to allow getting access to EJBObject metadata, handles, and for remove. Removing them does not break EJB 2.1. I guess we could/should remove this for EJBs that do not have an interface that extends EJBObject or EJBLocalObject
-
3. Re: EJBTHREE-786
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.
IIRC, the intent of getInvokedBusinessInterface was to figure out if there was a remote or local invocation. Gavin is actually the person that defined and demanded this feature in the spec. I have pinged him. -
4. Re: EJBTHREE-786
The spec is there to have a common expectation of an EJB 3 implementation. You can't diviate from it just because you find it more convenient for your users, that way we'll never pass TCK. If the spec was meant to define something that was best for the user it should have limited itself to that and not go into superfluous detail.
Do not get me wrong, I totally agree with getting the best for user, design & maintance.
The tests are: ejb30/bb/session/*/sessioncontext/*
They specifically test for invoked interfaces. -
5. Re: EJBTHREE-786
Sorry, I'm playing catchup.
Unless I'm missing something, his has nothing to do with the way we bind into JNDI. The developer currently has the option to bind home and business interfaces to the same name - the proxy will support both. However, the user also has the option to bind the 3 interfaces to different names (this is the default).
Carlo, are you suggesting that we have two different proxies - one that supports EJBObject and one that does not so that there is no clash between EJBLocalObject.remove() and a business remove()? -
6. Re: EJBTHREE-786
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
-
7. Re: EJBTHREE-786
I keep saying this to you....
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.
Also, it is *impossible* to know what interface was invoked upon if a set of interfaces of the same type (remote/local) have a method of the same signature.
The implementation of this, BTW, is very easy. Have knowledge on whether the method was invoked remotely or locally or through web services. Save the method hash transferred through the web layer. When somebody invokes getInvokedBusinessInterface, take this information and match the method hash to the appropriate interface. First one wins.
Why are we overengineering for this case? -
8. Re: EJBTHREE-786
The suggestion of forcing ejb3 beans that need to be accessible to ejb2.1 clients to have their interfaces implement EJBObject makes sense, especially since we already force them to specify a home interface. But as Carlo points out, this would cause TCK problems.
We can't remove the EJBObject implementation completely as that would break ejb2.1 clients who cast to EJBObject. -
9. Re: EJBTHREE-786
Having our proxies implement EJBObject is to be backwards compatible to EJB2.1 clients - isn't that a major point of the spec? I know the details aren't there, but the spirit of the spec is to be 2.1 client compatible.
Creating multiple proxies is a nightmare. It's confusing enough as it is since it's not in the spec.
Again, can't we just tell SEAM to change their method name and disallow EJBObject methods on Remote interfaces like EJB2.1 does? -
10. Re: EJBTHREE-786
Coming at this from a Seam (i.e. people using EJB3) perspective:
"bdecoste" wrote:
Having our proxies implement EJBObject is to be backwards compatible to EJB2.1 clients - isn't that a major point of the spec? I know the details aren't there, but the spirit of the spec is to be 2.1 client compatible.
Actually I thought *the* major point of EJB3 was to remove the arbitrary restrictions on what you can and can't do with your EJBs. Saying 'no, you can't define a method with the signature remove() on your business interface' strikes me as pretty arbitrary (from a user perspective). At the very least the current exception message is rubbish.Again, can't we just tell SEAM to change their method name
You can tell Gavin many things, it doesn't mean he listens ;)and disallow EJBObject methods on Remote interfaces like EJB2.1 does?
Perhaps I misunderstand you, but surely we are talking about Local and Remote interfaces (currently this exception is thrown for both) - if this restriction applies to just Remote interfaces it would be a start ;) -
11. Re: EJBTHREE-786
IIRC, we are allowed to define jboss specific metadata in order to pass a TCK test. Use your brains and think, what is the best solution for a typical user? Use that as the default behavior with additional metadata to satisfy the TCK bullshit.
-
12. Re: EJBTHREE-786
So to sum up a couple possible solutions and their drawbacks:
1) Have Proxy implement EJBObject/EJBLocalObject only if designated by the bean provider, ie:@Remote public interface MyBusiness extends EJBObject
This allows us to avoid signature collisions, but doesn't give us EJB2.1 Remote Interface views (EJB3 Spec 3.6.4) by default, and puts the onus on the bean provider to explicity designate EJBObject. Also makes it impossible to have both 2.1 Remote/Local interfaces "AND" methods defined by EJBObject at the same time. Looks like we also have to look into whether this is valid for TCK.
2) Create multiple Proxies, one for EJB3.0 Business Interface, one for EJB2.1 Remote Interface (EJBObject).
Drawback here is the number of changes we'd have to make, and the confusion to our user base by adding another Proxy into JNDI. I can imagine we'd get lots of requests on the user forum asking "when to use which/what's the differrence"? Also, we'd have to determine a default JNDI binding for the new Proxy as well as mechanism to override that (analagous to @RemoteBinding and its XML equivalent). Benefit is that we'd definitely be avoiding method collision, satifying 786, and not interfering w/ the TCK.
3) I don't believe we can simply tell Seam (or any other EJB3.0 Clients) that they can't use "remove" in their Business Interface:
Spec 3.4:The business interface of an EJB 3.0 session bean is an ordinary Java interface, regardless of whether local or remote access is provided for the bean. In particular, the EJB 3.0 session bean business interface is not one of the interface types required by earlier versions of the EJB specification (i.e., EJBObject or EJBLocalObject interface
4) 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.
As long as this doesn't violate spec or TCK, and is agreeable to Seam folks, 4 would be my vote.
S,
ALR -
13. Re: EJBTHREE-786
"ALRubinger" wrote:
4) 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 strikes me as a ugly. Is there no way this can be detected automatically or something? (and use an annotation as an override). -
14. Re: EJBTHREE-786
"pete.muir@jboss.org" wrote:
"ALRubinger" wrote:
4) 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 strikes me as a ugly. Is there no way this can be detected automatically or something? (and use an annotation as an override).
It's ugly because it puts the responsibility on the bean provider to dictate that his EJB won't supprt EJBObject methods. But what else can we use to detect automatically? Test for method signature collision and if so, don't implement EJBObject/EJBLocalObject? I don't think that's very intuitive to an application developer.
There's Carlo's suggestion that we create 2 Proxies; one to implement the Business Interface only (EJB3.0), and the other to support EJBObject/EJBLocalObject as well. I've listed some drawbacks to that approach; how do we feel this proposal? Any other's to weigh in on my recommendation of 4) ?
S,
ALR