Gregg Wonderly wrote:
On Jan 5, 2013, at 3:25 AM, Dan Creswell <[email protected]> wrote:
On 5 January 2013 05:10, Gregg Wonderly <[email protected]> wrote:
LookupLocator is not something that should be "passed around". It is
information that indicates a destination. The URL/URI form is all we should plan for,
for the future. This means that all dynamically discovered ServiceRegistrar instances,
should be identified as the URL string and then the appropriate protocol handler will be
able to extract the information from the URL/URI to connect and provide lookup services.
Gregg Wonderly
Indeed, I think it's serializable mostly because services typically
have a requirement to remember them/be stateful, treating config
purely as the initial startup source of lookup information. Which
means it's convenient to serialize this stuff to disk.
I guess this is the more interesting thing to discuss. What I am trying to say is that LookupLocator is a programming
construct, not a configuration construct. There are plenty of other things about "connecting to a
ServiceRegistrar" then the information that it currently contains. Peter highlighted some of those details, and I
think the basic evolution of Jini more or less missed tying all of this stuff together because of the "data"
and "functional" components of many of the classes where behavior and data, though used together, should not
of been together. Separating these two things for ServiceRegistrar connectivity, in particular would simplify a number
of issues about evolution, because extra data items in LookupLocator would be ignored by V1 and then V2 discovery as
needed. Certainly, the deserialization would need to be "versioned" appropriately, but that is possible.
Gregg Wonderly
Yes, LookupLocator doesn't have a readObject method and doesn't invoke
defaultReadObject(), if more fields are added to LookupLocator it will
fail to deserialize in an earlier version with StreamCorruptedException.
For that reason, the only option is to extend LookupLocator and include
the additional data there.
In fact LookupLocator serialization in River release 2.2 is broken, so
if anyone depends on it, wait for River 2.2.1.
Luckily LookupLocator is seldom serialized, it's built from multicast
discovery packets on most occasions.
We should probably check all River classes implementing Serializable can
be versioned. Serialization is complex, we should never accept the
default serial form, if we do, we should have a call to
defaultReadObject() as mentioned.
Effective Java 2nd Edition, chapter 11 has a good rant about
serialization gotcha's and patterns.
The only pattern it doesn't mention is the Serialization builder
pattern, available on our wiki, this is the only extensible
serialization pattern that avoids publishing internal object state. In
this pattern, the builder is responsible for serialization and construction.
Cheers,
Peter.
