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
