You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Sim IJskes (JIRA)" <ji...@apache.org> on 2009/11/10 15:57:27 UTC
[jira] Created: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
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
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.
[jira] Commented: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Sim IJskes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sim IJskes updated RIVER-325:
-----------------------------
Attachment: LookupLocator.java.patch
The patch to solve this issue.
> 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.
[jira] Assigned: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone reassigned RIVER-325:
-------------------------------------
Assignee: Peter Firmstone
> 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
> Assignee: Peter Firmstone
> 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.
[jira] Commented: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796905#action_12796905 ]
Peter Firmstone commented on RIVER-325:
---------------------------------------
>From river dev mail list:
Gregg Wonderly wrote:
> Are there any other issues that we need to deal with in adding a new constructor? I am wondering about "net.jini.discovery.timeout" as a system property. Do we want to provide the ability to pass this into the constructor too? I have cases where I want this to be short for some locators and long for others, but have to go with the global setting because of this implementation detail.
The LookupLocator is (in part) a value object. Its role, one of them, is pointing to the place where we can find a Registry. I did a scan of the sources, and i cannot find a place where another jini class actually retrieves the registry from the LookupLocator.
So any implementation that retrieves the ServiceRegistrar can set the individual timeout for the lookup with:
public ServiceRegistrar getRegistrar(int timeout)
I can foresee situations where this method isn't very helpfull to solve the problem of per-locator timeouts.
Gr. Sim
> 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.
[jira] Updated: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Gregg Wonderly (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregg Wonderly updated RIVER-325:
---------------------------------
Comment: was deleted
(was: I don't see a change for .equals() in the diff. Since you changed .hashCode() I think it would be wise to add the socket factory to the equals as well so that the use of the socket factory does make them different instances.
)
> 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.
[jira] Commented: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796907#action_12796907 ]
Peter Firmstone commented on RIVER-325:
---------------------------------------
>From river dev mail list:
Gregg Wonderly wrote:
> Wow, I had not chased through all this code. I had assumed that LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in fact it does not, and recreates all the processing itself and uses introspection to reference the getRegistrarMethod for constraints, but otherwise does not call it.
The whole jini package is also what you could call, rather TCP bound. The upper layer of JERI is transport neutral. I saw this as an opportunity to create a firewall traversing jini.
But when you look at other subsystems, you will see a direct dependence on Socket, and the assumption that an 'transport endpoint' is identified by a host and port (like the LookupLocator).
The strangest thing here, is altough the LookupLocator has this getRegistrar() only the port and host properties are used.
LookupLocator is used a _lot_, and to me it seems like it needs to be changed to a more transport neutral implementation.
It is possible to implement a LookupLocator via JERI. Reggie itself exports itself already. The only things we need is an agreed Uuid (configurable ofcourse) and a default for a ServerEndpoint export.
After this we can step-wise improve all the discovery subsystems to use the getRegistrar() method instead of relying on the properties.
A neat thing would also be, a configurable way to silence the existing unicast discovery server already built in Reggie.
Any objections? :-)
Gr. Sim
> 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.
[jira] Commented: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796908#action_12796908 ]
Peter Firmstone commented on RIVER-325:
---------------------------------------
>From river dev mail list:
Patrick Wright wrote:
> This sounds like a good direction to go in. I think that having the
> code throughout rely more on lookup methods like getRegistrar() could
> make certain types of testing easier--don't need to set up the
> infrastructure for socket-based testing if you can mock or stub the
> getRegistrar() method, for example.
Indeed, that would be nice. We could also decide that a LookupLocator is nothing more than a specialized URI for finding a Registrar, deprecate all implementation details, and provide a (configurable) factory to all subsystems that need to bootstrap via a known Registrar.
> An important question will be how to make any such changes backwards
Indeed! Maybe including a URI based factory will provide us with more room to maneuver.
Gr. Sim
> 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.
[jira] Commented: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796903#action_12796903 ]
Peter Firmstone commented on RIVER-325:
---------------------------------------
>From river dev mail list:
Peter Firmstone wrote:
> Lets add the constructor, it won't break anything and commit the patch, I've read the patch its straight forward, then we'll run the tests again.
> This is only a trivial change.
I guess you're refering to the patch for RIVER-71. I agree that the patch is a trivial change.
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.
> I'd also like to say thanks for the patch Sim and welcome to Apache River.
> 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.
[jira] Commented: (RIVER-325) LookupLocator is missing ways to
specify SocketFactory
Posted by "Gregg Wonderly (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776162#action_12776162 ]
Gregg Wonderly commented on RIVER-325:
--------------------------------------
I don't see a change for .equals() in the diff. Since you changed .hashCode() I think it would be wise to add the socket factory to the equals as well so that the use of the socket factory does make them different instances.
> 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.