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
>>
>
|