Ok, so I'm trying to hack all this together based on the feedback on
what might be good ways to handle all-in-one proxies for business
interfaces vs the required either way one-proxy-per-interface
approaches.
Couple notes, as Manu asked it doesn't look like failing the
deployment if all interfaces can be implemented is a compliant
option, but we certainly could have a flag that turns this on for
those that want to depend upon this feature. We can still try to
implement all interfaces, but if it's not possible best we can do is
log it.
As Mohammad mentioned it looks like some sort of ejbName +
businessInterface JNDI name is going to be required regardless now as
even if we want to support an all-in-one business interface proxy, we
still have to support the one-proxy-per-interface approach and that
means binding several entries into JNDI for the same bean. To pull
this off we're going to have to make some changes to the
JndiNameStrategy concept we have.
Also, these two methods of javax.ejb.SessionContext are *very*
related to this whole topic:
<T> T getBusinessObject(java.lang.Class<T> aClass);
java.lang.Class getInvokedBusinessInterface();
The first method is obviously a one-proxy-per-interface view of a
bean and this should work more compliantly once we get this stuff in.
The second method is a very big pain in that in order to support it
we have no choice but to make the proxy remember what "interface" it
is and either pass it into the container or make it available on the
thread. It would be great if we could use method.getDeclaringClass()
to figure out which business interface was invoked, but unfortunately
if there is any sort of shared inheritance among the business
interfaces (very common) it won't work reliably. We're actually
doing that now and it really needs to be fixed.
So we may end up having to change our container invoke signature to
look like this:
public Object invoke(Object deployID, Method callMethod, Object
[] args, Object primKey, Class interfaceClass) throws OpenEJBException;
I'm personally not particularly fond of doing that but it does fix a
few issues around not knowing exactly what kind of proxy called us
(remote interface, local interface, service endpoint interface,
business interface, exactly what business interface, etc.), so heads
up on a potential change to the Container interface.
This change would also allow us to some day "claw back" the interface
specific exception handling code that crept into the proxy handlers
putting it back into the container and then restoring the idea the
proxies only have to understand three exception types
(ApplicationException, SystemException, and Error). Right now the
proxy handlers catch those exceptions but then have to convert them
into what the spec says is the proper exception for that interface;
for example NoSuchObjectException vs. NoSuchObjectLocalException vs.
NoSuchEJBException.
Anyway, lots of moving parts in this one.
-David
On Apr 12, 2007, at 1:45 PM, Mohammad Nour El-Din wrote:
Hi All...
David, I've answered the question regarding to support all-in-one
proxy or
not. And regarding the naming convention of one-proxy-per-
interface, I think
we discussed it before on this thread long time a go, and I will
mention my
opinion just for refreshment. I suggested not use the deployment-id
as the
default JNDI, we should let the use specify it in the openejb-
jar.xml file,
or it should be created from the qualified name of the bean's class
and
append "/<interface-name". And AFAIR the specs use something like
this for
creating default JNDI names for referenced resources.
On 4/12/07, David Blevins <[EMAIL PROTECTED]> wrote:
This is biting us again. Here's the old thread for reference:
http://www.nabble.com/-openejb-dev--Concerning-JNDI-lookingup-
EJB3.0-beans-using-its-local-Home-and-Component-interfaces-
tf2056868s2756.html
We've had a similar thread since:
http://www.nabble.com/EJB3-lookup-and-JndiNameStrategy-
tf2754441s2756.html
The summary for those who don't like to read archives is that EJB 3
allows for multiple business interaces (local or remote) and this
creates complications in all sorts of things. We had simply ignored
that this was possible and only supported one business interface.
It'd be really nice if we could support creating a single proxy that
implemented all your business interfaces, so we didn't have to create
individual proxies for each business interface and then have to come
up with unique names for each in JNDI. We will probably have to do
that anyway, but at the very least it would be nice to try and create
a proxy that implements all the proxies and put it in JNDI under a
simpler name. There are some complications for doing this though,
i've tried to summarize them here:
http://cwiki.apache.org/OPENEJB/multiple-business-interface-
hazzards.html
I immediately thought, "Well that sucks, now I have to remove the
code I added yesterday for supporting all business interfaces on one
proxy." So I immediately started writing the above test cases and
document on why this was completely impossible to do.
But then I occurred to me that the hazzards of implementing multiple
business interfaces can only occur if the bean itself does *not*
implement it's business interfaces. In all cases where the bean
implements every business interface, which i think is the norm,
having one proxy doing the same is completely fine and I think is
what people would naturally expect.
So the question ultimately comes down to, should we support the idea
of the all-in-one proxy where possible or do we not support it at all
because it isn't possible under all circumstances?
I'd personally be inclined to say it is supported we just need to
check that your bean implements all your business interfaces before
attempting to create an all-in-one proxy, then log either way about
what we could or could not do.
Either way you cut it we're still going to need to support the one-
proxy-per-business-interface approach which means we'll have to have
a new naming convention for what they're called that likely
incorporates the name of the business interface in some way. This is
where the two quoted threads really come into play. We should
probably decide on what we want to do there as we're just about done
with our "first release" to do list we discussed a while back.
Thoughts all around? Throw in your $0.02 if you have 'em. As always
you don't need to be a committer to share your thoughts -- so pipe
up! :)
Going to post this to the user list also (edited down) and see if we
can't get some users to provide us with some preference as well.
-David
--
Thanks
- Mohammad Nour
