UnboundID LDAP SDK for Java 2.0.0-alpha1

We have just published an alpha release of the next major version of the UnboundID LDAP SDK for Java. This release includes the first official look at the LDAP persistence framework that I’ve been working on, which should make it much easier for developers to create Java applications that store information in an LDAP directory server. You can download this build on our SourceForge project page at https://sourceforge.net/projects/ldap-sdk/files/.

I’ve talked about the LDAP SDK persistence framework in previous posts, but there have been some significant changes since my last post about it. Further, while we still reserve the right to make changes before the official release if there is a very compelling reason to do so, we believe that the API we have now is suitable for the long term and will allow us to build additional features around it without breaking existing applications. Backward compatibility is very important for us, so we wanted to take some time to get it right. We’ve already gotten third-party feedback on the state of the API, but we’re definitely interested in getting other opinions. If you see something that doesn’t make sense or think could be improved, then please let us know, either via e-mail (ldapsdk-support@unboundid.com or ldap-sdk-discuss@lists.sourceforge.net) or our discussion forums (https://sourceforge.net/projects/ldap-sdk/forums/forum/1001257).

I’ll provide an example that demonstrates the use of this API in an upcoming post. There is some basic documentation, including a simple example, in the docs directory of the zip file, and that will be improved over time.

Some of the changes that have been made in the persistence framework since my last post include:

  • The LDAPPersister class now provides a getInstance method that you can use to obtain an instance for dealing with a specific type of object. This is a little cleaner than requiring you to invoke the constructor because you don’t have to repeat the class name as many times to satisfy Java’s constraints around the generics framework. It also allows instances to be cached and reused if another request is made for the same type of object.

  • Some of the classes used have been renamed to make them less confusing and more developer-friendly. LDAPFieldEncoder has been renamed to ObjectEncoder, since it is responsible for encoding more than just field values. The LDAPFieldGetter and LDAPFieldSetter annotation types have been renamed to LDAPGetter and LDAPSetter, respectively, since they work with methods rather than fields. The PersistSearchListener interface was renamed to ObjectSearchListener to avoid potential confusion with the persistent search control as defined in draft-ietf-ldapext-psearch.

  • The LDAPGetter and LDAPSetter annotation types have been updated so that the attribute element is no longer required to specify the name of the associated attribute. The attribute name can now be inferred from the name of the method. For example, if a method named “getGivenName” is marked with the LDAPGetter annotation, then it will be assumed that the name of the associated LDAP attribute is “givenName” unless that annotation includes an explicit attribute element.

  • The methods for performing searches in the persistence framework have been improved to give the developer better control over the search request that will be generated. It is now possible to include controls in the request, and you can also specify an additional search filter that will be ANDed with the filter generated from the object provided as a template. In addition, a number of searchForObject methods have been added that make it more convenient to perform a search that should only match a single entry.

  • The generate-source-from-schema tool has been updated so that it now provides better support for references to other entries. For any attributes with a DN syntax, the tool will now generate two types of getter methods: one for retrieving the DN(s) stored in that attribute, and another for obtaining the entries that they reference, decoded as objects of a particular type. For example, you could use this capability to retrieve a GroupOfNames object, and then easily iterate across the members as InetOrgPerson objects.

  • The persistence framework now provides a method that can be used to add schema definitions for the type of object you’re working with to an LDAP directory. This is primarily intended to be used as a convenience method, and it may not work with all types of directories since the process for updating directory server schema hasn’t been standardized, but it can be useful during the development and testing phases for an application designed for use with the persistence framework.

  • I have made some of the metadata-related classes public, including LDAPObjectHandler, FieldInfo, GetterInfo, and SetterInfo. These classes are used to perform some of the internal processing and validation, but they can also be used to obtain useful information about the structure of objects used with the persistence framework. You can use them to introspectively discover information about the fields, getter methods, and setter methods used for those objects.

3 thoughts on “UnboundID LDAP SDK for Java 2.0.0-alpha1

  1. That seems *really* interesting, and I will have a look as soon as possible.One thing that I would love to see (I don’t know if it’s already here, or not even in a forseable future) is to be able to have some value lazily retrieved. I think for example to group entries, where most of the time, you just want to display the name of the group, and some times, you want to see its (thousands of) members – and of course, I don’t want to load them when it’s not needed. So, I’m looking forward to see what will happen 🙂


  2. Lazy initialization is something that we have thought about and are planning to provide, but we have not yet gotten around to implementing it. We do have a form of it already for references (e.g., you can lazily iterate across the members of a group as User objects), but it will still currently retrieve the DNs for those members.One workaround that you can perform in the short term is to retrieve the group entry using the LDAP SDK outside of the persistence framework (e.g., using LDAPConnection.search or LDAPConnection.getEntry) and request only the attributes that you want. You can then use the LDAPPersister.decode method on that entry, and it will decode that partial entry to an object. As long as the member attribute isn’t marked as required for decoding, then that should succeed and and you can use the resulting object.Thanks for your comment and I’d be happy to hear any other feedback that you might have once you have gotten a chance to look at it.


  3. Your solution is rather interesting, and it seems that we have followed the same kind of thoughts. In my current project, my entities are interfaces, and their implementation are backed by an LDAPEntry with field mapping logic.Then, for each kind of entity, I have some factory methods that allows to transform LDAPEntry to their entity counterparts, and the other way. And so, when I need a lot of precision about what attributes should be retrieved, I use a raw LDAPConnection+search/getEntry and then build the "partial" entity from it, and when I don’t care, I use the entity repository. So, you seems to have bring some generalization on my raw ideas, and some nice sugar with annotations… I should really spend some time looking at your SDK :)Thanks,


Comments are closed.