directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Questionning some parts of the configuration, proposal
Date Sat, 13 Jun 2009 09:41:33 GMT
> 3) LdapService
> This class is now used only once in the ApacheDS class, as we don't need
> to define one instance to manage LDAP and another one for LDAPS : both
> are managed through a different transport. As a consequence, a flag is
> removed (enableSSL) : this flag depends on the SSL enabled transport
> presence.
> The getPort() method has been completed with a getportSSL() which
> returns the LDAPS associated transport port. The getPort() now returns
> the port for the non SSL transport.
Would be good to rename it to _LdapServer_, just to be consistent to the
naming of the other servers.

> 4) ApacheDS
> This class encapsulated the LdapServer and all the other servers. As a
> direct consequence of the transports modifcations, I have move dmost of
> the specific configuration up to the LdapService. The second impact is
> that we don't need to instanciate twice the LdapService (one for LDAP
> and anotherone for LDAPS), plus the reference to DirectoryService is now
> useless, as it's already present in the unique LdapService instance.
Emmanuel and I just discussed on IRC, it should be possible to get rid
of the ApacheDS class because it just grouped the LdapServices.

> o The LdapService bean has also been slighly modified, so that it can

>  <dnsServer>
>    <tcpTransports>
>      <tcpTransport port="8053"/>
>    </tcpTransports>
>    <udpTransports>
>      <udpTransport port="8053"/>
>    </udpTransports>
>    <directoryService>#directoryService</directoryService>
>  </dnsServer>

This transports configuration looks a bit chatty. A simpler solution
could be:

    <tcpTransport .../>
    <udpTransport .../>


  <tcpTransport .../>
  <udpTransport .../>

Kind Regards,

View raw message