river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon IJskes - QCG <si...@qcg.nl>
Subject Re: LookupDiscovery.ResponseListener configuration
Date Sat, 13 Oct 2012 12:48:46 GMT
On 12-10-12 16:22, Greg Trasuk wrote:
> OK, now I get it.  So we need a config entry for
> 'multicastDiscoveryPort' to go along with 'multicastDiscoveryHost'.  Or
> perhaps we should allow the host to be of the form 'host:port' and parse
> it out.

As to format: host:port looks better, most off river works with separate 
port. problem might be: 'host' without port implies default port, but in 
this case it is random. Who codes determines?

> I see what you mean.  I'm torn here between "what's right" and "what's
> convenient for developers".  I think in general, any time we use a host
> name, it should be configurable from a Configuration object, so having a
> utility class that provides a sensible local host object (and port, I
> guess) is the "right" way to do it.  At the same time, I realize that
> not everyone likes the Configuration mechanism, and even if they do,
> having to configure something as basic as the local host name is a
> nuisance.  So I can see your point about having a reasonable default.
> Perhaps we should try to do both.  Find any current usages (what text
> were you looking up to get 73 hits?) and make sure the components have
> the correct configuration options.  Then use a central utility class as
> the default rather than 'getLocalHost()' if no config is provided.

Both is ok with me. I cannot foresee a situation where you want to have 
different hostnames for different system parts, but i'm sure there is one.

I'm going to code the stub in, did you have an implementation ready?

Gr. Simon

QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

View raw message