Re: Export once, deserialize on subsequent restarts

Thanks Peter, at least now I know I just wasn't being dense. 

-----Original Message-----
From: Peter Jones - JavaSoft East [mailto:[email protected]] 
Sent: Tuesday, June 07, 2005 10:46 PM
To: Robert DiFalco
Cc: [email protected]
Subject: Re: Export once, deserialize on subsequent restarts

> Ok, this should be simple to do but I can't seem to figure it out. 
> 
> NOTE: I do not want to use RMID, ActivatableRef, or JINI.
> 
> All I want to do is export a stub for a server the first time it 
> starts, send that server's stub to a client, and have that client can 
> keep a persistent reference to it. Serializing the stub is easy on the

> client side. It's the serialization on the server side that is tricky 
> since I don't know how to deserialize it in a way that it gets the 
> same object table id.
> 
> So to restate, what I can't figure out how to do (without RMID 
> activation stuff) is to generate a stub once, serialize it locally, 
> and then on subsequent restarts, use the same serialized stub so that 
> it always has the same id in the object table.

The J2SE RMI API just doesn't provide a direct way to do this (export a
remote object so that it can be invoked through a previous-persisted
reference) other than with activation.  (Jini ERI supports this in that
a specific object ID can be passed to the BasicJeriExporter
constructor.)  One indirect approach would be to wrap the remote stub in
your own kind of faulting reference, similar to ActivatableRef or
net.jini.activation.ActivatbleInvocationHandler (more the latter,
because a dynamic proxy would clearly be convenient here), that performs
some sort of lookup operation (perhaps starting with a registry lookup)
when the underlying stub seems to be stale, to try to obtain a fresh
copy.

> I see RemoteProxy.getStub takes an ID as a parameter, but it is in 
> sun.rmi.*, is this class present on all JVM implementations? Am I on 
> the right track?

It is indeed possible to do this with sun.rmi.* APIs, but the resulting
solution would not be portable across J2SE implementations.
Case in point: sun.rmi.server.RemoteProxy does not exist in Sun's JDK
5.0 implementation.  If you're looking down that avenue despite all the
caveats[*], I would suggest looking at what
sun.rmi.registry.RegistryImpl does on construction for hints, as it also
needs to export with a fixed object ID.

-- Peter

[*] http://java.sun.com/products/jdk/faq/faq-sun-packages.html

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html