river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: RIVER-325: Use of socket factory in LookupLocator
Date Tue, 10 Nov 2009 17:53:32 GMT
Sim IJskes - QCG wrote:
> Gregg Wonderly wrote:
>> I'm just thinking out loud.  Adding constructor args can quickly cause 
>> variations to come about that change the number of constructors in the 
>> API in quadratic or worse rates.
>> It seems that we need to add two constructors in this case so that the 
>> default port for lookup doesn't have to be "knowledge" that is always 
>> reflected in the constructors if you use a factory.  Thoughts on one 
>> vs two constructors?  I haven't looked at your patch.
> The specification of SocketFactories will take place in the config 
> files. In this case i see no benefit in providing for another extra 
> constructor than:
> public LookupLocator(String host, int port, SocketFactory sf)
> We might document that sf = null means no factory (as it is now), and 
> port = -1 means default port (needs extra patch).

I really don't like the port==-1 thing, but could live with it I guess.  We must 
maintain the (String,int) signature constructor, so I was thinking that it would 
be better to add a (String,SocketFactory) cons just to be complete.  But, there 
is a precedence for not in many existing APIs.

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 

Gregg Wonderly

View raw message