On Oct 6, 2006, at 1:47 PM, David Blevins wrote:
Not sure how all this is going to play out in the remote protocol
(OPENEJB-91). We'll see. Off to work on that next.
Update on this effort. Just closed out:
OPENEJB-91 Remote business interfaces via EJBd Server
OPENEJB-96 Global JNDI Business Interface references
OPENEJB-158 iTest: StatelessRemoteBusinessIntfcTests
OPENEJB-184 iTest: StatefulRemoteBusinessIntfcTests
For a while I couldn't figure out how to get the business interface
support cleanly into the EJBd protocol, but after noodling on it for
a bit it I finally say a short path which wasn't a total hack. This
involved one change and in-process created the need for another fix-
to-come.
The first change is that now remote JNDI lookups no longer go to the
DeploymentIndex, they go straight into the local (aka, IntraVM)
global JNDI. We pull out the object, figure out what kind of proxy
it is, construct the appropriate response as before and send it back
along with its DeploymentIndex number. Subsequent calls go straight
to the deployment index. This is probably how the code should have
worked all along, but there was never a need to involve the local
global JNDI as before there was only one possible remote interface
type so it was safe to make several assumptions about the nature of
the JNDI name and the proxy type it would be referencing.
The "figure out what kind of proxy it is" part is the place that
involves a fix-to-come. All the proxy handlers create and return
ProxyInfo objects assuming that they are either an EJBHome or an
EJBObject. I've worked around this but this really needs to be
expanded as well. Again, before it was safe to assume you were
either an EJBHome or an EJBObject, but now that's no longer a safe
assumption. I plan to clean all that up, but really wanted to get
the most important functionality in first to make sure my refactoring
won't get out of hand. You know how it can be pulling threads on
sweaters....
Anyway, we're looking really good on the POJO bean support overall.
-David
