directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Questionning some parts of the configuration, proposal
Date Sat, 13 Jun 2009 22:12:27 GMT
Accordingly to Stefan,'s suggestions, I have slightly refactored the 
codee again, and it's much better now. Let's see the differences :

1) Transport
The transport classes (TcpTransport and UdpTransport) have been slightly 
changed. A new flag has been added to these class , enableSSL. It allows 
the transport to inject the SSL filter into the chain, if needed. It 
will be used for LDAP only.

2) ProtocolService
This class is the base for all the Server classes (NtpServer, 
ChangePaswordServer, KdcServer, DnsServer and LdapServer). The 
getDatagramAcceptor and getSocketAcceptor methods now take a Transport 
as an argument (that means a Server may support more than one Transport, 
like LDAP which support a TcpTransport with or without SSL)

3) LdapService
This class has been renamed LdapServer. It 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.

4) The Sync On Disk thread has been moved from the Service class to the 
DirectoryService class, and can be configured in this class (the 
syncPeriodMillis property has been moved to this class)

5) 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 LdapServer. The second impact is 
that we don't need to instanciate twice the LdapServer (one for LDAP and 
anotherone for LDAPS), plus the reference to DirectoryService is now 
useless, as it's already present in the unique LdapServer instance.

6) Server.xml
The server.xml file is impacted. Here are the main differences :
o The apacheDS bean has been simplified :

 <apacheDS id="apacheDS">
   <ldapService>#ldapServer</ldapService>
 </apacheDS>


instead of

 <apacheDS id="apacheDS"
           synchPeriodMillis="15000"
           allowAnonymousAccess="false">
   <directoryService>#directoryService</directoryService>
   <ldapService>#ldapService</ldapService>
   <ldapsService>#ldapsService</ldapsService>
 </apacheDS>

As we now have only one LdapServer, we don't need anymore to associate a 
DirectoryService to the ApacheDS class. The synchPeriodMillis has been 
removed, and has beento the DirectoryService, with the associated 
thread, as it's not ApacheDS business to sync the changes on disk. Last, 
not least, the allowAnonymousAccess flag is not needed anymore, as it's 
also carried by the LdapServer.

o The LdapService bean has also been renamed LdapServer and has been 
modified, so that it can take more than one transport :

 <ldapServer id="ldapServer"...>
   <tcpTransports>
     <tcpTransport id="tcp-ldap" port="10389" nbThreads="8" backLog="50" 
enableSSL="false"/>
     <tcpTransport id="tcp-ldaps" port="10686" enableSSL="true"/>
   </tcpTransports>

instead of

 <ldapServer id="ldapServer"...>
   <tcpTransport>
     <tcpTransport port="10389" nbThreads="8" backLog="50"/>
   </tcpTransport>

(Note that <tcpTransports> is now plural)

o Idem for the other servers :

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

instead of

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


Thanks !

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message