tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject EJB3 Business Interface proxies -- what do you want for features?
Date Thu, 12 Apr 2007 07:19:22 GMT
The title implies a much wider subject, so feel free to pipe in with  
any requests that may be not be related to the bulk of this email.

Anyways, there's an interesting facet to EJB 3 business interfaces,  
namely that you can have as many of them as you want.  One that note,  
you can also implement your business interfaces in your bean class  
whereas you could not with the old-style EJB 2.1 interfaces.  But as  
before, you do not have to implement your business interfaces in your  
bean class, you can simply have "matching methods" in the old ejb style.

So now here comes the question on what you as a user would like to  
see us do (followed by the tricky part which is why we're asking).   
What would you personally want, one proxy that implements all your  
business interfaces or one proxy per business interface?   The spec  
requires us to support the one-proxy-per-interface approach, but the  
all-interfaces-in-one-proxy approach could be supported... sort of....

The trick is that if you do *not* implement your multiple business  
interfaces and we try to create an all-in-one proxy, you could run  
into a couple different issues and one of them is really really  
nasty.  Here they are, the first one is the worst IMHO as I just ran  
into it and it's no fun :)

  http://cwiki.apache.org/OPENEJB/multiple-business-interface- 
hazzards.html

The important thing to remember is that these issues could only  
happen if your bean does *not* implement it's business interfaces.   
If it *does* implement it's business interfaces all these issues  
would be sorted out at compile time and you'd never run into them in  
the ejb container.

So, ... what would you want to see us do?  Should we support both or  
just the spec required approach?  If we were to support it, what  
would you like to see us do in the event that we encounter a bean  
that cannot be supported via the all-in-one proxy approach -- would a  
log message be fine or would you want to see us fail the deployment?

Thoughts?

-David


Mime
View raw message