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 
detail.

Gregg Wonderly

Mime
View raw message