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:11:28 GMT
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.

Gregg Wonderly

Sim IJskes - QCG wrote:
> Gregg,
> i'm not sure which view you are adressing, but it looks like you prove 
> my point. That is, don't use a configuration instance. :-)
> The problem with this example is that you force all LookupLocator's to
> use the same socketFactory.
> If the designers of Jini would have wanted a system-wide SocketFactory 
> or a configuration entry there should be some evidence of this. As the 
> Endpoints show us, they use SocketFactories and no Configuration entries.
> Gr. Sim
> Gregg Wonderly wrote:
>> I assume that you want to create a TCP socket factory that will do 
>> something special with connection management?  Can you describe what 
>> you need the factory to do?
>> Practically, expanding the constructor arguments is something to 
>> always consider carefully.  Adding a Configuration argument would 
>> allow the obvious construction technique shown below.
>> net.jini.core.discovery.LookLocator {
>>     socketFactory = new MySocketFactory();
>> }
>> org.my.something.Service {
>>     locators = new LookupLocator[] {
>>         new LookupLocator("jini://my.first.host",this);
>>     };
>> }
>> The problem is that if a factory is required for one instance, and not 
>> another, how do you convey this so that things can work correctly?
>> Gregg Wonderly

View raw message