Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (athena.apache.org: domain of
 oswaldo.cavalcanti@movecrm.com.br designates 200.196.247.139 as permitted
 sender)
Subject: [ApacheDS] lookup in EJB unnecessarely appending "JNDI Lookup"
	parameter
From: Oswaldo Cavalcanti Dantas <oswaldo.cavalcanti@movecrm.com.br>
To: users@directory.apache.org
Content-Type: multipart/alternative; boundary="=-MeYGwFj27aDH2guBQIAY"
Date: Fri, 28 Nov 2008 10:09:44 -0200
Message-Id: <1227874184.6760.10.camel@move-oswaldoj-l.movecrm.com.br>
Mime-Version: 1.0

--=-MeYGwFj27aDH2guBQIAY
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
http://directory.apache.org/apacheds/1.0/31-authentication-options.html
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=3Dexample,dc=3Dcom". In the EJB I can get the referenc=
e
to the ldap/example annotating the ctx with "@Resource(name =3D
"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=3Dusername,ou=3Dusers,dc=3Dexample,dc=3Dcom,dc=3Dexample,dc=3Dcom, like=
 it was
appending what I've set for the JNDI Lookup parameter in Glassfish.
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?

Regards,
=EF=BB=BFOswaldo Cavalcanti Dantas J=C3=BAnior


--=-MeYGwFj27aDH2guBQIAY--