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:[email protected]]
Sent: 10 November 2009 10:40
To: [email protected]
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
