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
