river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Use of socket factory in LookupLocator
Date Tue, 10 Nov 2009 14:29:49 GMT
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.



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

View raw message