Spring LDAP is designed to simplify LDAP programming in Java. Some of the features provided by the library are:

Consider a method that should search some storage for all persons and return their names in a list. Using JDBC, we would create a connection and execute a query using a statement. We would then loop over the result set and retrieve the column we want, adding it to a list.

Working against an LDAP database with JNDI, we would create a context and perform a search using a search filter. We would then loop over the resulting naming enumeration and retrieve the attribute we want, adding it to a list.

The traditional way of implementing this person name search method in Java LDAP looks like this. Note the code marked bold - this is the code that actually performs tasks related to the business purpose of the method - the rest is just plumbing:

By using the Spring LDAP classes AttributesMapper and LdapTemplate, we get the exact same functionality with the following code:

The amount of boilerplate code is significantly less than in the traditional example. The LdapTemplate search method makes sure a DirContext instance is created, performs the search, maps the attributes to a string using the given AttributesMapper, collects the strings in an internal list, and finally returns the list. It also makes sure that the NamingEnumeration and DirContext are properly closed and takes care of any exceptions that might happen.

Naturally — this being a Spring Framework sub-project — we will use Spring to configure our application>

For complete details of 2.2 refer to the changelog 2.2.0.RC1. The highlights of Spring LDAP 2.2 can be found below:

For complete details of 2.1 refer to the changelog 2.1.0.RC1 and 2.1.0 The highlights of Spring LDAP 2.1 can be found below.

While quite significant modernizations have been made to the Spring LDAP API in version 2.0, great care has been taken to ensure backward compatibility as far as possible. Code that works with Spring LDAP 1.3.x should with very few exceptions still compile and run using the 2.0 libraries without any modifications whatsoever.

The exception is a small number of classes that have been moved to new packages in order to make a couple of important refactorings possible. The moved classes are typically not part of the intended public API, and the migration procedure should be very smooth - wherever a Spring LDAP class cannot be found after upgrade, just organize the imports in your IDE.

You will probably encounter some deprecation warnings though, and there are also a lot of other API improvements. The recommendation for getting as much as possible out of the 2.0 version is to move away from the deprecated classes and methods and migrate to the new, improved API utilities.

Below is a list of the most important changes in Spring LDAP 2.0.

At a minimum, to use Spring LDAP you need:

In addition to the required dependencies the following optional dependencies are required for certain functionality:

The samples provide some useful examples on how to use Spring LDAP for common usecases.

The community support forum is located at http://forum.spring.io/forum/spring-projects/data/ldap, and the project web page is http://spring.io/spring-ldap/.

The initial effort when starting the Spring LDAP project was sponsored by Jayway. Current maintenance of the project is funded by Pivotal

Thanks to Structure101 for providing an open source license that has come in handy for keeping the project structure in check.

In this example we will use an AttributesMapper to easily build a List of all common names of all person objects.

The inline implementation of AttributesMapper just gets the desired attribute value from the Attributes and returns it. Internally, LdapTemplate iterates over all entries found, calling the given AttributesMapper for each entry, and collects the results in a list. The list is then returned by the search method.

Note that the AttributesMapper implementation could easily be modified to return a full Person object:

Entries in LDAP are uniquely identified by their distinguished name (DN). If you have the DN of an entry, you can retrieve the entry directly without searching for it. This is called a lookup in Java LDAP. The following example shows how a lookup for a Person object:

This will look up the specified dn and pass the found attributes to the supplied AttributesMapper, in this case resulting in a Person object.

LDAP searches involve a number of parameters, e.g.:

Spring LDAP provides an LdapQueryBuilder with a fluent API for building LDAP Queries.

Let’s say that we want to perform a search starting at the base DN dc=261consulting,dc=com, limiting the returned attributes to "cn" and "sn", with the filter (&(objectclass=person)(sn=?)), where we want the ? to be replaced with the value of the parameter lastName. This is how we do it using the LdapQueryBuilder:

For more information on the LdapQueryBuilder see Advanced LDAP Queries.

The standard Java implementation of Distinguished Name, LdapName, performs very well when it comes to parsing of Distinguished Names. However, in practical use this implementation has a number of shortcomings:

To simplify working with Distinguished Names, Spring LDAP provides an LdapNameBuilder, as well as a number of utility methods in LdapUtils that helps working with LdapName.

In Java LDAP, data can be modified in two ways: either using rebind or modifyAttributes.

A little-known — and probably underestimated — feature of the Java LDAP API is the ability to register a DirObjectFactory to automatically create objects from found LDAP entries. Spring LDAP makes use of this feature to return DirContextAdapter instances in certain search and lookup operations.

DirContextAdapter is a very useful tool for working with LDAP attributes, particularly when adding or modifying data.

Whenever an entry is found in the LDAP tree, its attributes and Distinguished Name (DN) will be used by Spring LDAP to construct a DirContextAdapter. This enables us to use a ContextMapper instead of an AttributesMapper to transform found values:

A shown above, we can retrieve the attribute values directly by name without having to go through the Attributes and Attribute classes. This is particularly useful when working with multi-value attributes. Extracting values from multi-value attributes normally requires looping through a NamingEnumeration of attribute values returned from the Attributes implementation. DirContextAdapter does this for you in the getStringAttributes() or getObjectAttributes() methods:

While very useful when extracting attribute values, DirContextAdapter is even more powerful for managing the details involved in adding and updating data.

When managing security groups in LDAP it is very common to have attribute values that represent distinguished names. Since distinguished name equality differs from String equality (e.g. whitespace and case differences are ignored in distinguished name equality), calculating attribute modifications using string equality will not work as expected.

For instance, if a member attribute has the value cn=John Doe,ou=People and we call ctx.addAttributeValue("member", "CN=John Doe, OU=People"), the attribute will now be considered to have two values, even though the strings actually represent the same distinguished name.

As of Spring LDAP 2.0, supplying javax.naming.Name instances to the attribute modification methods will make DirContextAdapter use distinguished name equality when calculating attribute modifications. If we modify the example above to: ctx.addAttributeValue("member", LdapUtils.newLdapName("CN=John Doe, OU=People")), this will not render a modification.

In the example above we are implementing BaseLdapNameAware, in order to get hold of the base LDAP path as described in Obtaining a reference to the base LDAP path. This is necessary because distinguished names as member attribute values must always be absolute from the directory root.

To illustrate the usefulness of Spring LDAP and DirContextAdapter, below is a complete Person Repository implementation for LDAP:

Object-relational mapping frameworks like Hibernate and JPA offers developers the ability to use annotations to map relational database tables to Java objects. Spring LDAP project offers a similar ability with respect to LDAP directories through a number of methods: in LdapOperations

Entity classes managed used with the object mapping methods are required to be annotated with annotations from the org.springframework.ldap.odm.annotations package. The available annotations are:

The @Entry and @Id annotations are required to be declared on managed classes. @Entry is used to specify which object classes the entity maps to and (optionally) the directory root of the LDAP entries represented by the class. All object classes for which fields are mapped are required to be declared. Note that when creating new entries of the managed class, only the declared objectclasses will be used.

In order for a directory entry to be considered a match to the managed entity, all object classes declared by the directory entry must match be declared by in the @Entry annotation. For example: let’s assume that you have entries in your LDAP tree that have the objectclasses inetOrgPerson,organizationalPerson,person,top. If you are only interested in changing the attributes defined in the person objectclass, your @Entry annotation can be @Entry(objectClasses = { "person", "top" }). However, if you want to manage attributes defined in the inetOrgPerson objectclass you’ll need to use the full monty: @Entry(objectClasses = { "inetOrgPerson", "organizationalPerson", "person", "top" }).

The @Id annotation is used to map the distinguished name of the entry to a field. The field must be an instance of javax.naming.Name.

The @Attribute annotation is used to map object class fields to entity fields. @Attribute is required to declare the name of the object class property to which the field maps and may optionally declare the syntax OID of the LDAP attribute, to guarantee exact matching. @Attribute also provides the type declaration which allows you to indicate whether the attribute is regarded as binary based or string based by the LDAP JNDI provider.

The @DnAttribute annotation is used to map object class fields to and from components in the distinguished name of an entry. Fields annotated with @DnAttribute will automatically be populated with the appropriate value from the distinguished name when an entry is read from the directory tree. If the index attribute of all @DnAttribute annotations in a class is specified, the DN will also be automatically calculated when creating and updating entries. For update scenarios, this will also automatically take care of moving entries in the tree if attributes that are part of the distinguished name have changed.

The @Transient annotation is used to indicate the field should be ignored by the object directory mapping and not mapped to an underlying LDAP property. Note that if a @DnAttribute is not to be bound to an Attribute, i.e. it is only part of the Distinguished Name and not represented by an object attibute, it must also be annotated with @Transient.

When all components have been properly configured and annotated, the object mapping methods of LdapTemplate can be used as follows:

Security groups in LDAP commonly contains a multi-value attribute where each of the values is the distinguished name of a user in the system. The difficulties involved when handling these kinds of attributes are discussed in DirContextAdapter and Distinguished Names as Attribute Values..

ODM also has support for javax.naming.Name attribute values, making group modifications very easy:

Modifying group members using setMembers, addMember and removeMember above, and then calling ldapTemplate.update(), attribute modifications will be calculated using distinguished name equality, meaning that the text formatting of distinguished names will be disregarded when figuring out whether they are equal.

The LdapQueryBuilder and its associated classes are intended to support all parameters that can be supplied to an LDAP search. The following parameters are supported:

An LdapQueryBuilder is created with a call to the query method of LdapQueryBuilder. It’s intended as a fluent builder API, where the base parameters are defined first, followed by the filter specification calls. Once filter conditions have been started to be defined with a call to the where method of LdapQueryBuilder, later attempts to call e.g. base will be rejected. The base search parameters are optional, but at least one filter specification call is required.

The examples above demonstrates simple equals conditions in LDAP filters. The LDAP query builder has support for the following criteria types:

There are occasions when you will want to specify a hardcoded filter as input to an LdapQuery. LdapQueryBuilder has two methods for this purpose:

You cannot mix the hardcoded filter methods with the where approach described above; it’s either one or the other. What this means is that if you specified a filter using filter() you will get an exception if you try to call where afterwards.

The recommended way of configuring Spring LDAP is using the custom XML configuration namespace. In order to make this available you need to include the Spring LDAP namespace declaration in your bean file, e.g.:

The ContextSource is defined using a <ldap:context-source> tag. The simplest possible context-source declaration requires you to specify a server url, a username, and a password:

This will create an LdapContextSource with default values (see below), and the url and authentication credentials as specified. The configurable attributes on context-source are as follows (required attributes marked with *):

The LdapTemplate is defined using a <ldap:ldap-template> tag. The simplest possible ldap-template declaration is the simple tag:

This will create an LdapTemplate instance with the default id, referencing the default ContextSource, which is expected to have the id contextSource (the default for the context-source element).

The configurable attributes on ldap-template are as follows:

As described above, a base LDAP path may be supplied to the ContextSource, specifying the root in the LDAP tree to which all operations will be relative. This means that you will only be working with relative distinguished names throughout your system, which is typically rather handy. There are however some cases in which you will need to have access to the base path in order to be able to construct full DNs, relative to the actual root of the LDAP tree. One example would be when working with LDAP groups (e.g. groupOfNames objectclass), in which case each group member attribute value will need to be the full DN of the referenced member.

For that reason, Spring LDAP has a mechanism by which any Spring controlled bean may be supplied the base path on startup. For beans to be notified of the base path, two things need to be in place: First of all, the bean that wants the base path reference needs to implement the BaseLdapNameAware interface. Secondly, a BaseLdapPathBeanPostProcessor needs to be defined in the application context:

The default behaviour of the BaseLdapPathBeanPostProcessor is to use the base path of the single defined BaseLdapPathSource (AbstractContextSource)in the ApplicationContext. If more than one BaseLdapPathSource is defined, you will need to specify which one to use with the baseLdapPathSourceName property.

Spring LDAP has built-in support for Spring Data repositories. The basic functionality and configuration is described here. When working with Spring LDAP repositories, please note the following:

Basic QueryDSL support is included in Spring LDAP. This support includes the following:

Pooling LDAP connections helps mitigate the overhead of creating a new LDAP connection for each LDAP interaction. While Java LDAP pooling support exists it is limited in its configuration options and features, such as connection validation and pool maintenance. Spring LDAP provides support for detailed pool configuration on a per-ContextSource basis.

Pooling support is provided by supplying a <ldap:pooling /> sub-element to the <ldap:context-source /> element in the application context configuration. Read-only and read-write DirContext objects are pooled separately (if anonymous-read-only is specified. Jakarta Commons-Pool is used to provide the underlying pool implementation.

Validation of pooled connections is the primary motivation for using a custom pooling library versus the JDK provided LDAP pooling functionality. Validation allows pooled DirContext connections to be checked to ensure they are still properly connected and configured when checking them out of the pool, in to the pool or while idle in the pool.

If connection validation is configured, pooled connections are validated using DefaultDirContextValidator. DefaultDirContextValidator does a DirContext.search(String, String, SearchControls) , with an empty name, a filter of "objectclass=*" and SearchControls set to limit a single result with the only the objectclass attribute and a 500ms timeout. If the returned NamingEnumeration has results the DirContext passes validation, if no results are returned or an exception is thrown the DirContext fails validation. The default settings should work with no configuration changes on most LDAP servers and provide the fastest way to validate the DirContext. If customization is required this can be done using the validation configuration attributes, described below.

The following attributes are available on the <ldap:pooling /> element for configuration of the DirContext pool:

The following attributes are available on the <ldap:pooling2 /> element for configuration of the DirContext pool:

Configuring pooling requires adding an <ldap:pooling> element nested in the <ldap:context-source> element:

In a real world example you would probably configure the pool options and enable connection validation; the above serves as an example to demonstrate the general idea.

While LdapTemplate contains several overloaded versions of the most common operations in DirContext, we have not provided an alternative for each and every method signature, mostly because there are so many of them. We have, however, provided a means to call whichever DirContext method you want and still get the benefits that LdapTemplate provides.

Let’s say that you want to call the following DirContext method:

There is no corresponding overloaded method in LdapTemplate. The way to solve this is to use a custom SearchExecutor implementation:

In your custom executor, you have access to a DirContext object, which you use to call the method you want. You then provide a handler that is responsible for mapping attributes and collecting the results. You can for example use one of the available implementations of CollectingNameClassPairCallbackHandler, which will collect the mapped results in an internal list. In order to actually execute the search, you call the search method in LdapTemplate that takes an executor and a handler as arguments. Finally, you return whatever your handler has collected.

If you prefer the ContextMapper to the AttributesMapper, this is what it would look like:

In the same manner as for custom search methods, you can actually execute any method in DirContext by using a ContextExecutor.

When implementing a custom ContextExecutor, you can choose between using the executeReadOnly() or the executeReadWrite() method. Let’s say that we want to call this method:

It’s available in DirContext, but there is no matching method in LdapTemplate. It’s a lookup method, so it should be read-only. We can implement it like this:

In the same manner you can execute a read-write operation using the executeReadWrite() method.

In some situations, one would like to perform operations on the DirContext before and after the search operation. The interface that is used for this is called DirContextProcessor:

The LdapTemplate class has a search method that takes a DirContextProcessor:

Before the search operation, the preProcess method is called on the given DirContextProcessor instance. After the search has been executed and the resulting NamingEnumeration has been processed, the postProcess method is called. This enables a user to perform operations on the DirContext to be used in the search, and to check the DirContext when the search has been performed. This can be very useful for example when handling request and response controls.

There are also a few convenience methods for those that don’t need a custom SearchExecutor:

The LDAPv3 protocol uses Controls to send and receive additional data to affect the behavior of predefined operations. In order to simplify the implementation of a request control DirContextProcessor, Spring LDAP provides the base class AbstractRequestControlDirContextProcessor. This class handles the retrieval of the current request controls from the LdapContext, calls a template method for creating a request control, and adds it to the LdapContext. All you have to do in the subclass is to implement the template method createRequestControl, and of course the postProcess method for performing whatever you need to do after the search.

A typical DirContextProcessor will be similar to the following:

Some searches may return large numbers of results. When there is no easy way to filter out a smaller amount, it would be convenient to have the server return only a certain number of results each time it is called. This is known as paged search results. Each "page" of the result could then be displayed at the time, with links to the next and previous page. Without this functionality, the client must either manually limit the search result into pages, or retrieve the whole result and then chop it into pages of suitable size. The former would be rather complicated, and the latter would be consuming unnecessary amounts of memory.

Some LDAP servers have support for the PagedResultsControl, which requests that the results of a search operation are returned by the LDAP server in pages of a specified size. The user controls the rate at which the pages are returned, simply by the rate at which the searches are called. However, the user must keep track of a cookie between the calls. The server uses this cookie to keep track of where it left off the previous time it was called with a paged results request.

Spring LDAP provides support for paged results by leveraging the concept for pre- and postprocessing of an LdapContext that was discussed in the previous sections. It does so using the class PagedResultsDirContextProcessor. The PagedResultsDirContextProcessor class creates a PagedResultsControl with the requested page size and adds it to the LdapContext. After the search, it gets the PagedResultsResponseControl and retrieves the paged results cookie, which is needed to keep the context between consecutive paged results requests.

Below is an example of how the paged search results functionality may be used: PagedResultsDirContextProcessor

Programmers used to working with relational databases coming to the LDAP world often express surprise to the fact that there is no notion of transactions. It is not specified in the protocol, and no LDAP servers support it. Recognizing that this may be a major problem, Spring LDAP provides support for client-side, compensating transactions on LDAP resources.

LDAP transaction support is provided by ContextSourceTransactionManager, a PlatformTransactionManager implementation that manages Spring transaction support for LDAP operations. Along with its collaborators it keeps track of the LDAP operations performed in a transaction, making record of the state before each operation and taking steps to restore the initial state should the transaction need to be rolled back.

In addition to the actual transaction management, Spring LDAP transaction support also makes sure that the same DirContext instance will be used throughout the same transaction, i.e. the DirContext will not actually be closed until the transaction is finished, allowing for more efficient resources usage.

Configuring Spring LDAP transactions should look very familiar if you’re used to configuring Spring transactions. You will annotate your transacted classes with @Transactional, create a TransactionManager instance and include a <tx:annotation-driven> tag in your bean configuraion.

In a real world example you would probably apply the transactions on the service object level rather than the repositort level; the above serves as an example to demonstrate the general idea.

A common use case when working against LDAP is that some of the data is stored in the LDAP tree, but other data is stored in a relational database. In this case, transaction support becomes even more important, since the update of the different resources should be synchronized.

While actual XA transactions is not supported, support is provided to conceptually wrap JDBC and LDAP access within the same transaction by supplying a data-source-ref attribute to the <ldap:transaction-manager> tag. This will create a ContextSourceAndDataSourceTransactionManager, which will then manage the two transactions, virtually as if they were one. When performing a commit, the LDAP part of the operation will always be performed first, allowing both transactions to be rolled back should the LDAP commit fail. The JDBC part of the transaction is managed exactly as in DataSourceTransactionManager, except that nested transactions is not supported:

The same thing can be accomplished for Hibernate integration by supplying a session-factory-ref attribute to the <ldap:transaction-manager> tag.

Spring LDAP manages compensating transactions by making record of the state in the LDAP tree before each modifying operation (bind, unbind, rebind, modifyAttributes, and rename). This enables the system to perform compensating operations should the transaction need to be rolled back.

In many cases the compensating operation is pretty straightforward. E .g. the compensating rollback operation for a bind operation will quite obviously be to unbind the entry. Other operations however require a different, more complicated approach because of some particular characteristics of LDAP databases. Specifically, it is not always possible to get the values of all Attributes of an entry, making the above strategy insufficient for e.g. an unbind operation.

This is why each modifying operation performed within a Spring LDAP managed transaction is internally split up in four distinct operations - a recording operation, a preparation operation, a commit operation, and a rollback operation. The specifics for each LDAP operation is described in the table below:

A more detailed description of the internal workings of the Spring LDAP transaction support is available in the javadocs.

While the core functionality of the ContextSource is to provide DirContext instances for use by LdapTemplate, it may also be used for authenticating users against an LDAP server. The getContext(principal, credentials) method of ContextSource will do exactly that; construct a DirContext instance according to the ContextSource configuration, authenticating the context using the supplied principal and credentials. A custom authenticate method could look like this:

The userDn supplied to the authenticate method needs to be the full DN of the user to authenticate (regardless of the base setting on the ContextSource). You will typically need to perform an LDAP search based on e.g. the user name to get this DN:

There are some drawbacks to this approach. The user is forced to concern herself with the DN of the user, she can only search for the user’s uid, and the search always starts at the root of the tree (the empty path). A more flexible method would let the user specify the search base, the search filter, and the credentials. Spring LDAP includes an authenticate method in LdapTemplate that provide this functionality: boolean authenticate(LdapQuery query, String password);

Using this method authentication becomes as simple as this:

Some authentication schemes and LDAP servers require some operation to be performed on the created DirContext instance for the actual authentication to occur. You should test and make sure how your server setup and authentication schemes behave; failure to do so might result in that users will be admitted into your system regardless of the DN/credentials supplied. This is a naïve implementation of an authenticate method where a hard-coded lookup operation is performed on the authenticated context:

It would be better if the operation could be provided as an implementation of a callback interface, thus not limiting the operation to always be a lookup. Spring LDAP includes the callback interface AuthenticatedLdapEntryContextMapper and a corresponding authenticate method: <T> T authenticate(LdapQuery query, String password, AuthenticatedLdapEntryContextMapper<T> mapper);

This opens up for any operation to be performed on the authenticated context:

In addition to the authenticate methods described above there are a number of deprecated methods that can be used for authentication. While these will work fine, the recommendation is to use the LdapQuery methods instead.

While the approach above may be sufficient for simple authentication scenarios, requirements in this area commonly expand rapidly. There is a multitude of aspects that apply, including authentication, authorization, web integration, user context management, etc. If you suspect that the requirements might expand beyond just simple authentication, you should definitely consider using Spring Security for your security purposes instead. It is a full-blown, mature security framework addressing the above aspects as well as several others.

LDAP Directory Interchange Format (LDIF) files are the standard medium for describing directory data in a flat file format. The most common uses of this format include information transfer and archival. However, the standard also defines a way to describe modifications to stored data in a flat file format. LDIFs of this later type are typically referred to as changetype or modify LDIFs.

The org.springframework.ldap.ldif package provides classes needed to parse LDIF files and deserialize them into tangible objects. The LdifParser is the main class of the org.springframework.ldap.ldif package and is capable of parsing files that are RFC 2849 compliant. This class reads lines from a resource and assembles them into an LdapAttributes object. The LdifParser currently ignores changetype LDIF entries as their usefulness in the context of an application has yet to be determined.

Two classes in the org.springframework.ldap.core package provide the means to represent an LDIF in code:

LdapAttribute objects represent options as a Set<String>. The DN support added to the LdapAttributes object employs the javax.naming.ldap.LdapName class.

The Parser interface provides the foundation for operation and employs three supporting policy definitions:

The default implementations of these interfaces are the org.springframework.ldap.ldif.parser.LdifParser, the org.springframework.ldap.ldif.support.SeparatorPolicy, and the org.springframework.ldap.ldif.support.DefaultAttributeValidationPolicy, and the org.springframework.ldap.schema.DefaultSchemaSpecification respectively. Together, these 4 classes parse a resource line by line and translate the data into LdapAttributes objects.

The SeparatorPolicy determines how individual lines read from the source file should be interpreted as the LDIF specification allows attributes to span multiple lines. The default policy assess lines in the context of the order in which they were read to determine the nature of the line in consideration. control attributes and changetype records are ignored.

The DefaultAttributeValidationPolicy uses REGEX expressions to ensure each attribute conforms to a valid attribute format according to RFC 2849 once parsed. If an attribute fails validation, an InvalidAttributeFormatException is logged and the record is skipped (the parser returns null).

A mechanism for validating parsed objects against a schema and is available via the Specification interface in the org.springframework.ldap.schema package. The DefaultSchemaSpecification does not do any validation and is available for instances where records are known to be valid and not required to be checked. This option saves the performance penalty that validation imposes. The BasicSchemaSpecification applies basic checks such as ensuring DN and object class declarations have been provided. Currently, validation against an actual schema requires implementation of the Specification interface.

While the LdifParser can be employed by any application that requires parsing of LDIF files, Spring offers a batch processing framework that offers many file processing utilities for parsing delimited files such as CSV. The org.springframework.ldap.ldif.batch package offers the classes necessary for using the LdifParser as a valid configuration option in the Spring Batch framework. There are 5 classes in this package which offer three basic use cases:

The first use case is accomplished with the LdifReader. This class extends Spring Batch’s AbstractItemCountingItemSteamItemReader and implements its ResourceAwareItemReaderItemStream. It fits naturally into the framework and can be used to read LdapAttributes objects from a file.

The MappingLdifReader can be used to map LDIF objects directly to any POJO. This class requires an implementation of the RecordMapper interface be provided. This implementation should implement the logic for mapping objects to POJOs.

The RecordCallbackHandler can be implemented and provided to either reader. This handler can be used to operate on skipped records. Consult the Spring Batch documentation for more information.

The last member of this package, the LdifAggregator, can be used to write LDIF records to a file. This class simply invokes the toString() method of the LdapAttributes object.

When there are a very large number of attribute values (>1500) for a specific attribute, Active Directory will typically refuse to return all these values at once. Instead the attribute values will be returned according to the Incremental Retrieval of Multi-valued Properties method. This requires the calling part to inspect the returned attribute for specific markers and, if necessary, make additional lookup requests until all values are found.

Spring LDAP’s org.springframework.ldap.core.support.DefaultIncrementalAttributesMapper helps working with this kind of attributes, as follows:

This will parse any returned attribute range markers and make repeated requests as necessary until all values for all requested attributes have been retrieved.

spring-ldap-test bring an embedded ldap server based on ApacheDS or UnboundID.

Download the dependency below:

Maven:

Gradle:

ApacheDS dependencies:

Maven:

Gradle:

An embedded ldap server is created using the bean below:

spring-ldap-test provided a mechanism to populate the ldap server using org.springframework.ldap.test.LdifPopulator. Create the bean as follow:

Another way to work against an embedded ldap server is using org.springframework.ldap.test.TestContextSourceFactoryBean which allow to use and populate it.

Also, org.springframework.ldap.test.LdapTestUtils provide methods to work with embedded ldap server programmatically.

UnboundID dependencies:

Maven:

Gradle:

An embedded ldap server is created using the bean below:

spring-ldap-test provided a mechanism to populate the ldap server using org.springframework.ldap.test.unboundid.LdifPopulator. Create the bean as follow:

Another way to work against an embedded ldap server is using org.springframework.ldap.test.unboundid.TestContextSourceFactoryBean which allow to use and populate it.

Also, org.springframework.ldap.test.unboundid.LdapTestUtils provide methods to work with embedded ldap server programmatically.