[warning: long post only for purposes of spreading info, you don't
really have to read it]
I removed a bit of cruft we didn't need and something probably no one
understood anyway. Posting about it as it's kind of neat and a
fundamental concept of having a distributed technology. Here is a
related bit of javadoc around the concept of a SpecialProxyInfo.
/*
* Business methods that return EJBHome or EJBObject references
to local
* beans (beans in the same container system) must have the
return value
* converted to a ProxyInfo object, so that the server can
provide the client
* with a proper remote reference. Local remote references are
implemented using
* the org.openejb.core.ivm.BaseEjbProxyHandler types, which
should not be returned
* to the client. Non-local remote references are assumed to be
serializable and valid
* return types for the clients.
*
* If the reference is a local remote reference a subtype of
ProxyInfo is returned. The subtype
* is a org.openejb.core.ivm.SpecialProxyInfo. This class type is
useful when the calling server
* is the IntraVM server. Instead of creating a new remote ref
from the proxy the IntraVM takes
* a short cut and reuses the original local remote reference --
they are thread safe with no synchronization.
*
* See Section 2.2.1.2.5 Remote References of the OpenEJB
specification.
*/
The concept is one of the first added to OpenEJB (early 2000) and
something we later realized we didn't need -- rather that it doesn't
work completely enough. As the javadoc says, this was the technique
we used to ensure things created and only usable inside the vm
weren't passed outside to app clients where they would be utterly
useless. That part was good, but the silly thing was assuming you
could prevent this by scanning the return types from remotely
executable methods. Objects travel in graphs and a local-only object
could be buried quite deep in a graph and will still need to be
replaced with something the client can use.
It was at that point (early 2001) that we added the ApplicationServer
interface and instituted the proxy replace strategies that truly
solve this issue as well as these tests to ensure it'd never break.
The javadoc is very detailed of the breadth of the issue.
http://fisheye.codehaus.org/browse/openejb/trunk/openejb2/modules/
openejb-core/src/main/java/org/openejb/spi/ApplicationServer.java?r=2707
These tests were created at the same time and carefully watch our
back, there's one set for each container type.
http://fisheye.codehaus.org/browse/openejb/trunk/openejb3/openejb-
itests/src/main/java/org/openejb/test/stateless/
StatelessRmiIiopTests.java?r=2679
The real critical bit of all this is that the ApplicationServer
interface is one of our core concepts that managed to survive in
OpenEJB 1, 2 and 3. If you want to implement a remote protocol, you
must implement the ApplicationServer interface. The good news is
that's the only interface you have to implement.
Anyway, lots of changes and lessons learned around that little concept.
-David
