Already a long time on my list of things to tackle is customization of the object identification layer.
The case I have is that in general all services deployed in one JVM reuse the same ServerEndpoints so that all services can utilize the same port number, to save from having to configure each service or to prevent from using random ports which are not stable over time. The result of this is that when one service is down but others are still exported in the same JVM and an inbound request is received the client will get a java.rmi.NoSuchObjectException. I won't start over the discussion how a client should deal with that, the consensus seems to be that it is a definite exception so we assume the client will give up. Well that is fine, but that means that when I bring a 'persistent' service down for a bugfix so that it is only gone for a limited amount of time that the object identification layer should send another type of RemoteException, e.g. a java.rmi.ConnectException as that shouldn't be considered a definite exception by the client. One could even come up with custom standardized RemoteExceptions for these cases in which you mention the expected time the service will be online again, but for now I'm more interested in getting rid of NoSuchObjectException. From reading the specs at the net.jini.jeri package documentation it seems that there is not much plugability for the object identification layer: "In order to use a different implementation of the object identification layer, a deployer needs to use a custom Jini ERI exporter class, which should support specifying an InvocationLayerFactory and ServerEndpoint for controlling the invocation and transport layer implementations." I don't want to clone BasicJeriExporter while all I need is some interception mechanism when an object endpoint identifier is missing in the internal object table. When missing the interceptor should be called and allow the implementation of that interceptor decide whether it can provide a customized exception. Looking through the spec and source code I couldn't find any code that seemed to be responsible for throwing the NoSuchObjectException directly until I stumbled into BasicObjectEndpoint which seem to create the NoSuchObjectException at the client side based on the first byte (0x00) send by the server. There are various possibilities to achieve what I want but as I don't want to modify the specs for BasicEndPoint I'm thinking of a custom dispatcher (which I already have) that will write a proper RemoteException in the output stream based on certain conditions. The point is how to make BasicJeriExporter aware of the interception mechanism I require: a) clone BasicJeriExporter and sort it out myself, allows for a very quick and dirty solution but no reuse by others; b) a service provider mechanism that search for the first service provider that implements a com.sun (for now) specific interface. That service provider can implements its own initialization mechanism to hook in the required logic that verifies whether the object identifier unknown to the internal export tables need custom dispatching. c) something I haven't thought of given me being a virgin in this part of the code/spec. -- Mark
