Configuration of ApacheDS with Spring
This section describes the overall structure of the server configuration, which uses Spring.
ApacheDS and Spring
There are several options to configure ApacheDS. For instance you can practically do everything programmatically if you embed the server in a Java component.
For this guide we assume a standard installation of ApacheDS run standalone, and the default mechanism to configure this deployment option is (in almost all cases) changing the file server.xml, which is located in the conf directory of your ApacheDS instance. The file is composed of bean definitions, because configuration in ApacheDS 1.5 is done with the help of the Spring Framework.
Despite the fact that the default server.xml shipped with the product is somewhat long, a quick look with the help of the Spring IDE displays that the structure is rather simple:
Most configuration tasks can be accomplished by modifying the properties of existing bean definitions, or (e.g. for a new partition) by adding new beans of certain types and wiring them to the configuration.
Note that the picture above does not show all properties available in the configuration. Only those are visible for which the default server.xml contains a value. There are more, and in case of absence the default value is chosen. Feel free to browse the file to get an impression about further options – several other features controlled by properties are commented out.
Using Apache Directory Studio for configuration
Future versions of Directory Studio will support creation and manipulations of these configurations files. Stay tuned.
ApacheDS configurable parameters
Apache Directory Server has many different configuration parameters. This page summarize all the possible parameters, and what are the default values for all of them.
Interceptors
We have currently 16 possible interceptors we can use in the server. It's important to understand that some of them are mandatory, and other can be activated or disabled. The interceptors order is also very important : most of them can't be moved up or down, without severely impact the server behaviour.
Here is the list of the mandatory interceptors, and the order in which they should appears in the configuration file :
Interceptor |
Mandatory |
Order |
---|---|---|
AciAuthorizationInterceptor |
Yes |
4 |
AuthenticationInterceptor |
Yes |
2 |
ChangeLogInterceptor |
No |
7 |
CollectiveAttributeInterceptor |
Yes |
13 |
DefaultAuthorizationInterceptor |
Yes |
5 |
EventInterceptor |
Yes |
14 |
ExceptionInterceptor |
Yes |
6 |
KeyDerivationInterceptor |
No |
10 |
NormalizationInterceptor |
Yes |
1 |
OperationalAttributeInterceptor |
Yes |
8 |
PasswordPolicyInterceptor |
No |
9 |
ReferralInterceptor |
Yes |
3 |
ReplicationInterceptor |
No |
16 |
SchemaInterceptor |
Yes |
11 |
SubentryInterceptor |
Yes |
12 |
TriggerInterceptor |
No |
15 |
The following table represents the same interceptor in the order they must appear :
Interceptor |
Mandatory |
---|---|
NormalizationInterceptor |
Yes |
AuthenticationInterceptor |
Yes |
ReferralInterceptor |
Yes |
AciAuthorizationInterceptor |
Yes |
DefaultAuthorizationInterceptor |
Yes |
ExceptionInterceptor |
Yes |
ChangeLogInterceptor |
No |
OperationalAttributeInterceptor |
Yes |
PasswordPolicyInterceptor |
No |
KeyDerivationInterceptor |
No |
SchemaInterceptor |
Yes |
SubentryInterceptor |
Yes |
CollectiveAttributeInterceptor |
Yes |
EventInterceptor |
Yes |
TriggerInterceptor |
No |
ReplicationInterceptor |
No |
AciAuthorizationInterceptor :
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <aciAuthorizationInterceptor/> ...
AuthenticationInterceptor :
Set<Authenticator> : The list of supported Authenticators. Currently, we have Anonymous, Simple and Strong authenticators. We can just list the associated beans in the server.xml file. Here is a sample of such a configuration :
<defaultDirectoryService ... ... <interceptors> ... <authenticationInterceptor> <s:property name="authenticators"> <s:set> <!-- Define a new Simple authenticator with a cache of 50 elements --> <s:bean id="simpleAuthenticator" class="org.apache.directory.server.core.authn.SimpleAuthenticator"> <s:constructor-arg value="50"/> </s:bean> <!-- Define a Strong authenticator --> <s:bean id="strongAuthenticator" class="org.apache.directory.server.core.authn.StrongAuthenticator"/> </s:set> </s:property> </authenticationInterceptor> ...
The possible values are : AnonymousAuthenticator, SimpleAuthenticator and StrongAuthenticator, out of which the SimpleAuthenticator has a possible parameter, the cache size (an integer value)
CollectiveAttributeInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <collectiveAttributeInterceptor/> ...
DefaultAuthorizationInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <defaultAuthorizationInterceptor/> ...
ChangeLogInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <changeLogInterceptor/> ...
EventInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <eventInterceptor/> ...
ExceptionInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <exceptionInterceptor/> ...
KeyDerivationInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <keyDerivationInterceptor/> ...
NormalizationInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <normalizationInterceptor/> ...
OperationalAttributeInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <operationalAttributeInterceptor/> ...
PasswordPolicyInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <passwordPolicyInterceptor/> ...
ReferralInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <referralInterceptor/> ...
ReplicationInterceptor
This interceptor manage the replication. It has many parameters, most of them being defined in a specific clas : ReplicationConfiguration. Let's describe those parameters.
Each instance has a name, which allows multiple instances of the server to be present on the same machine, but with possible replication between them.
First, let see an exemple
<defaultDirectoryService ... ... <replicationInterceptor> <configuration> <replicationConfiguration logMaxAge="5" replicaId="instance_a" replicationInterval="2" responseTimeout="10" serverPort="10390"> <s:property name="peerReplicas"> <s:set> <s:value>instance_b@localhost:1234</s:value> <s:value>instance_c@localhost:1234</s:value> </s:set> </s:property> </replicationConfiguration> </configuration> </replicationInterceptor> ...
The ReplicationConfiguration bean contains those parameters :
Name |
Type |
Default value |
Description |
---|---|---|---|
logMaxAge |
int |
7 |
Maximum days of change logs stored |
replicaId |
String |
none |
ID of the replica |
replicationInterval |
int |
5 |
Replication data exchange interval (seconds) between two replicas |
responseTimeout |
int |
60 |
response timeout value (seconds) for each sent message |
serverPort |
int |
7846 |
TCP/IP port number that the interceptor listens to |
csnFactory |
CSNFactory |
DefaultCSNFactory |
The CSNFactory for generating CSNs |
peerReplicas |
Set<String> |
none |
The remote peer replica list |
store |
DerbyReplicationStore |
none |
The ReplicationStore which stores the change log |
Some of those parameters are complex types : csnFactory, peerReplicas and store. Let's describe those parameters more in detail
csnFactory
This parameter define the class factory to use to create a CSN (Change Sequence Number). ApacheDS has a default implementation, which will be used if this parameter is not given, otherwise one can provide his own factory. In this case, a constructor parameter must be given, the ReplicaId ( a String, 1 to 8 chars long).
peerReplicas
This is the list of remote replicas. Each replica is defined by a name, a host address and a port. The syntax must be :
<replicaid>@<host>:<port>, like ServerAAA@10.1.2.7:1234.
store
This is the backend used to store element to replicate. We are currently using Derby, but one might want to change that, if the new ReplicaStore instance implement this interface. This is not a common usage to change this parameter, usually, it's better to keep it absent, using the default value.
I personally think that this parameter should not be exposed, as the csnFactory.
SchemaInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <schemaInterceptor/> ...
SubentryInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <subentryInterceptor/> ...
TriggerInterceptor
No configuration. We can just activate the interceptor by adding it to the list of interceptors :
<defaultDirectoryService ... ... <interceptors> ... <triggerInterceptor/> ...