[
https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796970#action_12796970
]
Peter Firmstone commented on RIVER-325:
---------------------------------------
>For the constructor issue i've opened another, RIVER-325.
>I will try to make the impact of the patch as low as possible.
>The only concern i have with it, is if we expect the locator to be
> marshalled from one participant to another, and when versions differ.
>The class resides in jini-core, so will never be loaded over the network.
>In this case, we should change the serialVersionUID and provide
>compatibility serialization support, and i'm not sure if this will work out ok.
Is there some way we can cause the class to be loaded over the network?
Perhaps OSGi bundles may be useful here, using that framework to ensure
compatible Classes in different nodes via automatic upgrading, in any case this
looks like a point at which we will have to break backward compatibility.
In this case breaking backward compatibility may be worthwhile, if this is the
case perhaps there may be a case to do some refactoring that breaks backward
compatibility.
A better pattern for Serialization, for new classes in future, is using a
serialization proxy (not to be confused with jini proxies), during
marshalling, the proxy is created, marshalled, sent over the network and passed
to a class constructor during unmarshalling. Then when you want to change your
implementation, you simply extend the proxy and pass that implementation
around, then your constructor can check with instanceof() for the proxy and
provide defaults for different states. You loose any new state when passing to
earlier versions, but you remain compatible. The Serialization proxy pattern
solves the whole drama of getting locked in to implementation details caused by
Serializable. See Effective Java 2nd Ed for details.
Similarly you can pass around a builder as a Serialization Proxy, then you can
return any implementation you want with the builder, very powerfull indeed.
The builders only concern is the the data, it doesn't need to worry about
synchronization / concurrency or method implementations, separating concerns
and simplifying.
> LookupLocator is missing ways to specify SocketFactory
> ------------------------------------------------------
>
> Key: RIVER-325
> URL: https://issues.apache.org/jira/browse/RIVER-325
> Project: River
> Issue Type: Improvement
> Components: net_jini_discovery
> Reporter: Sim IJskes
> Priority: Minor
> Attachments: LookupLocator.java.patch
>
>
> LookupLocator has no way to specify a SocketFactory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
