[Design of EJB 3.0] - Re: EJBTHREE-786
by ALRubinger
"pete.muir(a)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(a)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(a)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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090763#4090763
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090763
18 years, 2 months
[Design of EJB 3.0] - Re: EJBTHREE-786
by ALRubinger
"pete.muir(a)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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4090748#4090748
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4090748
18 years, 2 months