Again I wanted to summarize some very important IRC conversations I just had with David Jencks. As you
know we're still in the phase (I) where we're removing configuration beans to directly configure the protocol
components themselves. We are however running into interesting problems which require some decisions
that are not necessarily write or wrong but a matter of a trade off.
I will use the NTP protocol as the example for this discussion however the problem applies to all
protocols which run on both TCP and UDP.
NtpServer represents a protocol service that responds to NTP protocol requests. Each NtpServer has its
own port and uses either UDP or TCP but not both since the NtpServer is a single endpoint. Presently
ApacheDS will launch two of these servers: one for UDP and one for TCP on the same port. There is a
single NtpConfiguration bean which is used to configure both NtpServers.
Our present dilemma is whether or not to expose the configuration of two NtpServer components in the
server.xml that are wired directly by Spring or to just expose a single NtpConfiguration object that is configured
and used to launch these two servers.
Dave makes a good point that if we wire the NtpConfiguration instead of two NtpServers then the configuration
is simpler and more succinct. Although I don't see why someone would run the NTP provider for UDP on a different
port than the one for TCP the users will still be required to make the ports match since the same configuration
bean is used for both servers. Also both UDP and TCP will be required to run together where the user does not
have a choice.
In most cases if NTP or any other UDP/TCP capable IP protocol is to run, both servers often run on the same port
if not being absolutely required to do so. I think most clients presume that the UDP or TCP service automatically
runs on the same port by default. It might be more common for users to enable only TCP or UDP but still this will
not be that common.
IMO I agree with David's points however I have the following thoughts:
(1) The additional configuration of two NtpServers independently is not much at all especially when smart defaults
are used in which case it's just one extra tag without properties.
(2) We give users the flexibility if they want to run just a UDP server or just a TCP server instead of requiring
(3) We give users the option of running both UDP and TCP on different ports if they desire for whatever odd
(4) We stay true to our goal with the removal of configuration beans in preference for wiring the components
(5) There's full transparency that two separate components for handling a protocol are being used with different
(6) We're not delegating life-cycle management of the protocol to a composite object that must start and stop
the pair of protocol servers together. I find this troubling because it may create issues for us down the line
with other container frameworks where we just want to ask for a protocol service with specific properties and
get a handle on it.
With these considerations I feel we aught to stick to the original plan and require the configuration of two servers
if that's what the user wants. If one server is desired then that's fine too. We have more flixibility with the per
server configuration than grouping both together within an NtpConfiguration object which manages both their
life-cycles in unison.
I think we're going to continue this conversation some more however if anyone else has an opinion or thoughts on
the matter that we're not thinking about please do comment.