From dev-return-14519-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Dec 03 22:31:45 2006 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 80387 invoked from network); 3 Dec 2006 22:31:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Dec 2006 22:31:44 -0000 Received: (qmail 81807 invoked by uid 500); 3 Dec 2006 22:31:52 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 81769 invoked by uid 500); 3 Dec 2006 22:31:52 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 81758 invoked by uid 99); 3 Dec 2006 22:31:52 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Dec 2006 14:31:52 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Dec 2006 14:31:43 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id F014D714317 for ; Sun, 3 Dec 2006 14:31:22 -0800 (PST) Message-ID: <24102731.1165185082980.JavaMail.jira@brutus> Date: Sun, 3 Dec 2006 14:31:22 -0800 (PST) From: "Emmanuel Lecharny (JIRA)" To: dev@directory.apache.org Subject: [jira] Reopened: (DIRSERVER-169) Incorrect SearchResult name and "compare" failure using CoreContextFactory In-Reply-To: <999156397.1138633472771.JavaMail.jira@ajax.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ] Emmanuel Lecharny reopened DIRSERVER-169: ----------------------------------------- Reopened to be sure we have investigated all the consequences of the fix. > Incorrect SearchResult name and "compare" failure using CoreContextFactory > -------------------------------------------------------------------------- > > Key: DIRSERVER-169 > URL: http://issues.apache.org/jira/browse/DIRSERVER-169 > Project: Directory ApacheDS > Issue Type: Bug > Components: core > Environment: OS X, > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-83) > Java HotSpot(TM) Client VM (build 1.5.0_05-48, mixed mode, sharing) > Reporter: Luke Taylor > Assigned To: Alex Karasulu > Fix For: 1.5.0, 1.0-RC4 > > Attachments: DIRSERVER169TestCase.java, LdapTestServer.java, TestCase.zip > > > Attached is a test case following on from my post a while back to the mailing list, viz: > My setup is like this: > I have a simple DIT with a root "dc=acegisecurity,dc=org". This has two subcontexts "ou=people" and "ou=groups" for my users and roles respectively. When the test base class instantiated, I create a > MutableStartupConfiguration and add a partition to it with the suffix "dc=acegisecurity,dc=org". I then create a context with this configuration as follows: > env.setProperty( Context.PROVIDER_URL, "dc=acegisecurity,dc=org" ); > env.setProperty( Context.INITIAL_CONTEXT_FACTORY, > CoreContextFactory.class.getName()); > env.putAll( cfg.toJndiEnvironment() ); > serverContext = new InitialDirContext( env ); > When I need a context in my tests it is created the same way. > Bind authentication works fine in both scenarios. I have problems with two things when trying to use CoreContextFactory : > 1. The name returned by a search. When I do a search for a user in the directory, I get back the full DN rather than the name relative to the context I search in. So if I call > ctx.search("ou=people", "(uid={0})", new String[] {"bob"}, ctls); > on a context obtained as above, I get back a SearchResult with name > "uid=bob,ou=people,dc=acegisecurity,dc=org" > whereas with the full server (or OpenLDAP) I get > "uid=bob" > as expected. This then unfortunately leads to an attempt to bind with an an unknown DN which causes the infinite recursion problem. > 2. Performing "compare" operations. I had problems with this before, as reported in > http://issues.apache.org/jira/browse/DIRLDAP-77 > but this now works with the full server, thanks to Emmanuel's speedy response. Running the same search code against a context obtained from CoreContextFactory fails however. A compare is never performed and the search returns an empty enumeration. Is there some way I can get my client code (as posted in JIRA): > SearchControls ctls = new SearchControls(); > ctls.setReturningAttributes(new String[0]); > ctls.setSearchScope(SearchControls.OBJECT_SCOPE); > String filter = "(userPassword={0})"; > NamingEnumeration results = ctx.search(dn, filter, new > Object[]{password.getBytes()}, ctls); > to trigger a compare call on the context? The compare/search also fails for non-binary attributes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira