directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Lansing" <>
Subject RE: [ApacheDS] authentication problem
Date Mon, 19 Dec 2005 20:43:16 GMT

> How about your other problem? Does it still exist? You told us about a 
> code snippet like this:
>              InitialDirContext ctx = new InitialDirContext();
>              LdapName name = new LdapName("ou=users");
>              Attributes attributes = new LockableAttributesImpl();
>              attributes.put("uid", "jdoe");
>              NamingEnumeration ne =, attributes);
> Can you provide information about the JNDI config you use (file 
>, for instance)? Is it the LDAP provider from Sun, and 
> are you talking about the network with plain LDAP?

The other problem was my fault. I didn't realize that the password attribute
was now returned as a byte[]. (I think formerly it was a String.)

We have embedded ApacheDS in our application. We could use the Sun provider,
but by embedding the directory, it starts up and stops at the same time as
our other services. Of course we can also talk to the directory itself with
an LDAP client (JXplorer, say).

Our application is based on the Globus ws-core, which uses JNDI for all of
its configuration, based on (lots of) jndi-config.xml files. We added an
additional layer by writing a custom InitialContextFactory that returns
InitialContexts that wrap the LDAP ones, but translate J2EE style names to
LdapNames (i.e., java:/comp/env/foo gets translated to dn=foo, dn=env,
dn=comp, ou=j2ee, ou=system), and vice-versa. In this way we keep all of the
Globus configuration in the directory, where it can be dynamically modified,
persisted, etc. without changing any of their code.


View raw message