Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4AF978DD.9040906@zeus.net.au>
Date: Wed, 11 Nov 2009 00:29:49 +1000
From: Peter Firmstone <jini@zeus.net.au>
Organization: Zeus Project Services
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Use of socket factory in LookupLocator
References: <4AF91D96.10506@qcg.nl>
	 <64efa1ba0911100026p895c8c8h6c1cf46806a3e121@mail.gmail.com>
	 <4AF92C7F.2070606@qcg.nl>
	 <64efa1ba0911100132m23a585el539b1be64bc9cecd@mail.gmail.com>
	 <4AF9345C.1080503@qcg.nl>
 <64efa1ba0911100219i793fd984o91e32c101aa04beb@mail.gmail.com>
 <4AF942FA.4030705@qcg.nl>
 <964EAC824495234A86F3C47DA8BD8AAD17773B@sucden-exch.sucden.co.uk>
In-Reply-To: <964EAC824495234A86F3C47DA8BD8AAD17773B@sucden-exch.sucden.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

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'd also like to say thanks for the patch Sim and welcome to Apache River.

Cheer,

Peter.

Besides the comment on Jira states:

An RFE for Reggie: make it so that the ServerSocket used to      
handle unicast discovery is created from a configurable ServerSocketFactory.    
We've run across this when trying to run Reggie behind a firewall where a range 
of ports is exposed--if there were a configurable ServerSocketFactory, then we  
could specify one that allocated a ServerSocket within that range.              
                                                                                
(I realize we could configure a fixed port number or open up the default        
unicast discovery port in the firewall, but we'd like to avoid hardcoding       
portnumbers into our configurations as much as possible, and also don't want to 
preclude running more than one instance of Reggie on a given host.)
Posted Date : 2006-07-14 14:43:40.0


Tom Hobbs wrote:
> I'm siding with Sim on this one.  It seems strange to use a
> (comparatively) heavy weight Configuration object for this when just
> overloading the constructor makes sense for the class concerned.  (And
> has minimal impact elsewhere).
>
> Two caveats though;
>
> 1) It's an *overloaded* cntr, please don't remove any of the existing
> ones
> 2) Leave applying the patch until after the AR2 release
>
> I'd also be wary of discouraging the submission of a patch because we
> can't decide exactly what it should look like.  I'm not convinced that
> the arguments for the Configuration object are stronger than the
> arguments to make this an additional cntr.  Given that, and the fact
> that someone has a patch already waiting, let's go with whatever we have
> ready.
>
> Of course, if the cntr approach appears to be wrong at some point in the
> future, *whoever creates the Configuration object patch* can deprecate
> it.
>
> As some one way brighter than me once said, "a man who has never made a
> mistake, has never made anything".  I say use this patch, at the very
> least we can say that the River community has made something.
>
> Tom
>
> -----Original Message-----
> From: Sim IJskes - QCG [mailto:sim@qcg.nl] 
> Sent: 10 November 2009 10:40
> To: river-dev@incubator.apache.org
> Subject: Re: Use of socket factory in LookupLocator
>
> Patrick Wright wrote:
>   
>> I think the point may be that the non-Configuration parameters to a
>> class are generally those which must be supported by a qualifying
>> implementation; whatever is in the Configuration is an internal
>> decision of a specific implementation. I think host and port make
>> sense as part of the LL API, whereas how sockets are created or
>> configured is an implementation decision for a Jini implementation.
>> For example, an implementation may decide to keep the socket factory
>> itself private to the class, while allowing certain socket parameters
>> like timeout to be configured via Configuration.
>>     
>
> It was a sensible decision to include a socket factory parameter in 
> SslEndpoint, TcpEndpoint, HttpEndpoint. They all don't use a config 
> instance.
>
> A LookupLocator does not need a config either. The constructor can be 
> the same as an Endpoint (host,port,factory).
>
> Gr. Sim
>
>