Ok, some updates.
The code that creates intravm proxy handlers and proxies has been
cleaned and consolidated significantly to the point where we can dig
deeper into this functionality.
The high-level changes were to:
- Eliminate all code throughout the system that assumed it knew
how to create a proxy
- Have the Container create ProxyInfo objects with only the
DeploymentInfo and the primary key and leave knowledge of the proxy
type and interfaces to the Server.
After having gone through the refactoring and cleaning it's clear it
should have been this way all along as it's not only simpler,
smaller, and more flexible but it's much more inline with the basic
concept that the Container and Server are separate.
It's always fun when you get to remove more code than you add and
*gain* functionality, flexibility, and simplicity. Love it!
We should be able to support all sorts of proxy styles now (all in
one, one each, some mix of both maybe, etc.) without any extra burden
on the containers at all, which is just great.
Next step is to update the naming code to build the proxies we need
and allow for a flexible way for users to control the names using
some of the ideas we've discussed. With the cleaned up code it will
be way easier for us to change and adjust that part of the puzzle
without much headache at all.
-David
On Apr 13, 2007, at 2:38 PM, David Blevins wrote:
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
