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:

<ntpServer port=123>
   <#directoryService/>
   <#udpAcceptor/>
   <#tcpAcceptor/>
</ntpServer>

Configures both UDP and TCP transports on port 123.

<ntpServer port=123>
   <#directoryService/>
   <#tcpAcceptor/>
</ntpServer>

Configures only TCP on port 123.

<ntpServer port=123>
   <#directoryService/>
   <#udpAcceptor/>
</ntpServer>

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
do exist. 

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 ...

On 10/10/07, David Jencks <david_jencks@yahoo.com> wrote:
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.

Ok so you broke it out to have a UdpNtpServer and a TcpNtpServer which are in them selves what you
deem one implementation approach I guess right?

Then there is this NtpConfiguration which starts both together as a configuration bean + manager for the
other two services?

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>

Ok then this would be close to what I was pointing out above but it uses this ApacheDS reference
instead of feeding in the MINA components.  I would like to see these configuration objects go away
all together without even the ServiceConfiguration base class.  Instead an AbstractServer object can
be defined and used for server implementations like NtpServer with the base configuration details in
it.

This way we don't have a configuration bean + additional code to start and stop subordinate services.
So let me list it out:

AbstractServer (or AbstractService )

    Replaces ServiceConfiguration as base class for protocol servers.  This is the common
    denominator for all servers running in ApacheDS.  It may need some properties moved
    into some subtypes since the present ServiceConfiguration has more than the common
    denominator. 

XxxServer

    Takes IoAcceptors.  Some servers need one for each transport some may only need one.
    Some may take both but optionally.  These protocol servers then manage binding to the
    appropriate port for the transports.  If somewhere down the line configurations differ
    dramatically for one transport verses another this model still works.  You can still have a
    UdpXxxServer and TcpXxxServer subtyping the base XxxServer or directly extending the
    AbstractServer base class.  In these transport specific subtypes they may only expose
    getter/setter pairs for IoAcceptors for their respective transport.  So this model is most
    flexible for whatever comes down the pike.

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>

This might not at all be necessary if we attack this problem like the way suggested above.

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.

I think we can do it right and be pure.  We just need to think about it more but at some point we must stop and
implement it so we're not stuck thinking forever.  This is why your commit was a great move it helps look at an
example we can take to the next step of the discussion.  Thanks for it.

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.

Yes this would be good.  I noticed you made these servers dependent on the server-jndi module just to
pass in the ApacheDS reference.  I'd like to see this dependency go away where the dependency is really
on the core and MINA components.

More below ...

<OT>

There's an extreme danger here of making a mountain out of a
molehill :-)
These comments are counter productive and whether deliberate or not are threatening to bypass
further reasoning about this matter by trivializing the discussion as being excessive.  You are entitled
to this opinion but not to shorting this discussion and just doing it some way. 

I'm not trying to force anything and am listening to your suggestions since I value them.  I pushed to
champion your effort to remove these configuration beans and brought about the bigbang effort even
though others were worried about it's impact.  This move has pushed out my personal objectives as
well but we believed in your ideas.  This is why I am following through with them and trying to do it
to the best of my ability by completely removing these configuration beans.

This is a two way street.  As I extend the benefit of the doubt and patience you're way you owe me
some patience as well.  Not saying you're not giving it.  But the comment above is a subtle indicator
that your patience is wearing thin.  When this happens stop and think about the big step we all took
to meet your wishes.

Also consider that you are new to this project and may not have complete information to foresee
problems down the line.  On the flip side, you're in a unique position to really show us how wrong
some of our design decisions are because of your fresh new perspective.  Plus you're not a newbie
and a solid engineer as witnessed by your past contributions.  We know how incredible you are.

So bear with me because something in the back of my head is telling me to do this right with
a little more discussion.  We'll get to the bottom of this but let's consider all our options. 

</OT>

Alex