Ok I had some sleep and low and behold the ideas came to me :). I think I have a clear picture of
what we need to do to handle this properly. Let me describe that here then try to figure out how
that fits with what you have done and described below.
First if Emmanuel is right about NTP needing both protocol end points on the same port for both
transport protocols (UDP/TCP) then there is no need to have twice the configuration. Then
something like these combinations would suffice:
Configures both UDP and TCP transports on port 123.
Configures only TCP on port 123.
Configures only UDP on port 123.
Note that I did not pass in <#apacheDS/> which is not needed since this service will depend on the
core directory service plus the MINA components. Depending on which IoAcceptor is set the respective
transport protocol is used. If both are set then both transports are to be used.
So instead of having the NtpServer class just deal with setting up a single endpoint for one transport
protocol it will handle all endpoints for all transport protocols and no more configuration bean. The
component is wired directly but how it's wired determines what is enabled.
If the other protocols obey the same requirements where both transport endpoints are needed on the
same port then we can follow this same pattern. We just have to watch for the special cases if they
Now what impact does this have on OSGi and on configuration in DIT for the future. I don't know that
yet and it's something to think about.
Ok now inline for discussing your changes ...
In rev 583375 I moved all the non-ldap protocol servers into independent components and provided 2 NTP implementations as a basis for further discussion.
NtpConfiguration illustrates the approach of a single component to configure both udp and tcp versions of the same protocol. This could trivially be enhanced with flags to enable/disable the tcp or udp choices. If we decide on this approach I would rename the class NtpServer.server.xml configuration of this looks like:<ntpConfiguration ipPort="80123"><apacheDs>#apacheDS</apacheDs></ntpConfiguration>
AbstractNtpServer, TcpNtpServer, and UdpNtpServer illustrate the approach of a component per protocol version. server.xml configuration of this looks like:<udpNtpConfiguration ipPort="81123"><apacheDs>#apacheDS</apacheDs></udpNtpConfiguration><tcpNtpConfiguration ipPort="81123"><apacheDs>#apacheDS</apacheDs></tcpNtpConfiguration>
I don't have a strong preference between these two approaches and think they both are equally good components. I think the first, single component managing both servers, will be easier for our users to understand and configure, although it might be conceptually slightly less pure.
Whatever the outcome of this discussion I think the next step, other than conforming the protocol servers to whatever we decide, is to move the mina setup code in ApacheDS into a separate component: this would replace the ApacheDS reference in all these servers.
There's an extreme danger here of making a mountain out of a