Introduction

There is two ways to initialize the server :

1. As a standelone server
2. As an embeded server

 Both initialization are different, for the user perspective, but not from the developper perspective, as the first initializtion system embed the server, just adding some specific mechanism to stop the server (remember that the server can be launched as a daemon)

The server initialization is done in two steps. The first one read the confuguration, and set all the necessary structures, and the second step start the server.

Initialization

This is done by reading the server.xml file, which is a Spring based document. As we refer many classes into this file, they will be instanciated on the fly.

The following classes are created :

The following schema represent the properties set by this configuration file :

Configuration initialization

During this phase, we instanciate the MutableServerStartupConfiguration, which will initialize a lot of structures, through the call to those three methods :

• setDefaultAuthenticatorConfigurations
• setDefaultBootstrapSchemas
• setDefaultInterceptorConfigurations

then we will initialize the two declared partitions, system and example

setDefaultAuthenticatorConfigurations() method

This method initialize the authentication methods. At the moment, we support only Simple authentication (ie with a password) or Anonymous authentication.

Each authenticator is stored in a MutableAuthenticatorConfiguration object, which associate a name and a dedicated class.

For information about authentication mechanisms, open this page : Authentication Mechanisms in ADS

setDefaultBootstrapSchemas() method

In this method, we will load all the default schemas, which are :

• CoreSchema
• CosineSchema
• ApacheSchema
• InetorgpersonSchema
• JavaSchema
• SystemSchema
• CollectiveSchema

Those schema are transofmed into classes by a maven plugin, and they initiate all the needed structures to handle Ldap ObjectClass, Attributes, Comparator, MatchingRules, etc...

The description of this setup can be found in this page : Schema loading

It can be noted that at this stage, we don't load any other schema. Users defined schema are loaded after the initialization of the server has been done.

setDefaultInterceptorConfigurations() method

Here, we will create the list of all existing interecptors. Each interceptor is an instance of the MutableInterceptorConfiguration class.

The instanciated interceptors are :

• normalizationService
• authenticationService
• referralService
• authorizationService
• defaultAuthorizationService
• exceptionService
• schemaService
• subentryService
• operationalAttributeService
• collectiveAttributeService
• eventService
• triggerService

For more informations about Interceptors, go to this page : Interceptors

Other parameters 

When this basic initialization is done, this phase is achieved by the loading of default values :

System and example partitions initialization

Those two partitions are instances of the MutableBTreePartitionConfiguration class.

The initialization will create a Jdbm partition, instanciate one MutableIndexConfiguration per indexed attribute (this class stores the indexed attribute's OID with an cache size - this size is expressed as the number of attributes to keep in the cache -),

The last piece of information we have to set is the entry associated with the top level element of the partition : the context entry. As a partition is characterized by a suffix and an associated entry, this is the place to declare this entry. For instance, for the dc=example, dc=com partition, the context entry is :

objectClass: top
objectClass: domain
objectClass: extensibleObject
dc: example

 
It should be clear that this entry  must be valid. We can consider that the partition suffix is the entry's DN. In our example, this is dc=example, dc=com.

Environment setting 

After this first initialization done, we have to augment the envirnoment with some specific properties. Up to this point, the environment contains :

We will add those properties :

Now, we have to reach the last two steps : instanciate the server before starting it, and create a thread which will be responsible of saving modified entries from the cache to the disk.

Server instanciation

The configuration has been read, we now have to instanciate the server. This is done throw a JNDI invocation of the InitialDirContext() method :

new InitialDirContext( env );

where env is the environment we have set in the previous steps. This method calls the getInitialContext() from the ServerContextFactory class which has been associated with the java.naming.factory.initial property.

Launching the server .