tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: EJB3 Business Interface proxies -- what do you want for features?
Date Thu, 12 Apr 2007 17:13:25 GMT
After thinking about this a bit longer, I don't think my idea is  
possible.  The problem is the looked-up-interface can not be combined  
with the all-implemented-interfaces set due to the  
"UndeclaredThrowableException" problem.

It would be nice to be able to have two simple strategies 1) all- 
implemented 2) not-implemented.  Unfortunately, the  
"IllegalArgumentException" problem doesn't let us reliably combine  
even the implemented interfaces.  For example, the following is legal  
Java code:

     public interface One {
         One run(Object o);
     }

     public interface Two {
         Two run(Object o);
     }

     public class OneTwo implements One, Two {
         public OneTwo run(Object o) {
             return null;
         }
     }

But you can't generate a java.lang.reflect.Proxy with both the One  
and Two interfaces due to the "IllegalArgumentException" problem.

I'm not sure we can do anything here (without custom bytecode  
generation, yuck).

-dain

On Apr 12, 2007, at 9:36 AM, Dain Sundstrom wrote:

> When I write a bean, I'll most likely have my bean implement all of  
> the interfaces, so I would prefer to get an all-in-one-proxy.  I  
> can see a case where I decide to add an interface after a library  
> has shipped, so I think the "doesn't have to implement rule" is a  
> good get out of jail free card :)
>
> So how about a compromise....
>
> proxy = looked-up-interface + all-implemented-interfaces
>
> This way if you implement your interfaces, you get the cool all-in- 
> one proxy and you still can use unimplemented interfaces.
>
> -dain
>
> On Apr 12, 2007, at 12:19 AM, David Blevins wrote:
>
>> 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