directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] lookup in EJB unnecessarely appending "JNDI Lookup" parameter
Date Fri, 28 Nov 2008 13:00:44 GMT
Oswaldo Cavalcanti Dantas wrote:
> Hello,
> I'm developing an EJB to do some operations like password verification
> against a LDAP server and creation of users in such server.
> For tests, I'm using ApacheDS for LDAP and GlassFish for the EJB
> container. Everything works as documented in
> in the "Sample code with JNDI".
> Running as an EJB, I want to use the LDAP as an External JNDI Resource
> so the application server can manage a pool for me, but that gives me a
> problem when I call the lookup method on the DirContext.
> Basically, in GlassFish I set the "JNDI name" to "ldap/example" and the
> "JNDI Lookup" to "dc=example,dc=com". In the EJB I can get the reference
> to the ldap/example annotating the ctx with "@Resource(name =
> "ldap/example")", wich is correctly authenticated and allows me to do
> the search for the user.
> After finding it and getting it's dn, the "ctx.lookup(dn);" line gives
> me a NameNotFoundException where I can see it tried to find a
> uid=username,ou=users,dc=example,dc=com,dc=example,dc=com, like it was
> appending what I've set for the JNDI Lookup parameter in Glassfish.
As stated in JNDI context API :
"All naming operations are relative to a context. The initial context 
implements the Context interface and provides the starting point for 
resolution of names."

So if you setup the initial context to point on dc=example,dc=com, every 
subsequent operation will be relative to this starting point. If you do 
things like a JNDI lookup with this context using "dc=example,dc=com" as 
a parameter, then the real DN will be 
"dc=example,dc=com,dc=example,dc=com", as the initial context already 
points to "dc=example,dc=com".

You have to do a ctx.lookup( dn )  where the DN does not contains the 
root context (here, you have to remove the last two elements, ie 
dc=example and dc=com).

> Doing some string manipulation and comparing the hash password instead
> of doing the lookup, I have a working version, but as I understand it
> isn't the recomended solution as I'll have to code a lot of
> verifications that are already done inside the LDAP server (like
> encoding the password with the appropriate algorithm).
> So, has anyone encountered a similar problem?
Eveybody using JNDI is suffering the same pain :/ ...

JNDI sucks (TM).

cordialement, regards,
Emmanuel L├ęcharny

View raw message