Spring LDAP 1.2.1 released

[ulsa]

Dear Spring Community,
Spring LDAP version 1.2.1 has been released. This is a minor release, introducing an interesting new feature and a few bug fixes, including the following:

Pooling library
Eric Dalquist has contributed a powerful pooling library. Pooling support is provided by PoolingContextSource, which can wrap any ContextSource and pool both read-only and read-write DirContext objects. Jakarta Commons-Pool is used to provide the underlying pool implementation.

ldapbp dependency fixed
Fixed a problem in AbstractContextSource which led to an unnecessary reference to the LDAP Booster Pack (ldapbp).

And as a reminder for those of you who haven't yet upgraded to 1.2:

Package restructuring
Due to some package inconsistencies the package structure was modified in version 1.2-RC1 of Spring LDAP. Consequently, version 1.2.1 is NOT a drop-in replacement for version 1.1.2. A detailed upgrade guide is however provided, and upgrading should not present very much trouble.

For a full list of all changes, refer to the changelog
Binaries are available for download here

As always comments, improvement suggestions and patches are most welcome, here on the forum or on the JIRA issue tracker

Regards,
The Spring LDAP Team

[sthomps]

Is it possible with this latest release to provide both pooling and failover for multiple ldap servers? It seems to be a one or the other based on the examples and src code.

The main problem I have is when a pool has been established and a server goes down. Trying to connect to the server results in the client waiting forever for a connection to be returned. This has since been remedied in JDK 6.
http://java.sun.com/docs/books/tutor...adtimeout.html

What I'm currently doing is extending the LdapContextSource, overriding the getDirContextInstance method, and creating a separate timerthread then running test search on the context.

[edalquist]

How are you doing multi-server failover? The pooling code was developed specifically for this use case though we have multiple LDAP servers behind a single load-balanced virtual IP. With this setup we never have a connection attempt to the IP hang but existing connections can 'go bad' if the LDAP server for that connection goes down.

The pooling code wouldn't solve the read timeout problem itself since the issue is that the JDK LDAP API doesn't appear to give you a way to specify how long the underlying Socket.read() operation should wait until JDK6.

The pooling code could however be used to wrap your custom LdapContextSource and pool the 'good' connections that it returns. You would also likely need to implement your own DirContextValidator and use the same monitor-thread functionality on the validation query if the timeLimit setting in DefaultDirContextValidator is not enough to deal with servers that have gone down.

I hope that helps,
-Eric

[sthomps]

Unfortunately in my case our servers are not behind a single virtual ip. The failover is currently relying on the default one provided by the JDK Ldap API when passing in multiple URL's.

This works great if say the ldap port goes down on the server but not if the entire server goes down and can't be reached.

It seems odd that something like this has taken until JDK 6 to resolve.

Thanks

[edalquist]

I wonder if some sort of tee ContextSource would be a possible solution? It would take a List of ContextSources each configured to connect to a single server. If one fails it would move on to the next in the list to try and get a connection from. The individually configured ContextSources would still need the monitor thread logic it sounds like you've already written but it may be at least a more robust way to deal with this.

It is a bit frustrating that much of the built in LDAP support seems to necessitate such work-arounds though.

[jordanh]

The 1.2.1 spring-ldap-tiger maven pom file (http://repo1.maven.org/maven2/org/sp...iger-1.2.1.pom) currently reads:

<modelVersion>4.0.0</modelVersion>
<groupId>org.springframework.ldap</groupId>
<artifactId>spring-ldap-tiger</artifactId>
<name>Spring LDAP Tiger</name>
<version>1.2</version>

I believe the version should be 1.2.1.

[ulsa]

Yes, that was a mistake on our part, although it's only incorrect in the spring-ldap-tiger pom. The spring-ldap pom is OK.

We did test it just now, using a dependency like this:

<dependency>
  <groupId>org.springframework.ldap</groupId>
  <artifactId>spring-ldap-tiger</artifactId>
  <version>1.2.1</version>
</dependency>

The strange thing is that it seems to work. It resolves the spring-ldap-tiger.jar to 1.2.1, and also the transitive spring-ldap.jar to 1.2.1 (the MANIFEST files indeed show 1.2.1 for both). So perhaps this has no practical consequences. Let us know if there are any problems.

[jordanh]

I can verify that in my environment spring-ldap-tiger 1.2.1 works fine under maven. I am also unsure what consequences the version mistake in the pom file could cause, if any. Thus far it has worked fine for me.