Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 25807 invoked from network); 2 Apr 2006 20:11:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Apr 2006 20:11:06 -0000 Received: (qmail 23794 invoked by uid 500); 2 Apr 2006 20:11:06 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 23753 invoked by uid 500); 2 Apr 2006 20:11:05 -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 23741 invoked by uid 99); 2 Apr 2006 20:11:05 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Apr 2006 13:11:05 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Apr 2006 13:11:04 -0700 Received: from ajax (localhost.localdomain [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id A9ECC6ACB1 for ; Sun, 2 Apr 2006 21:10:43 +0100 (BST) Message-ID: <467488009.1144008643677.JavaMail.jira@ajax> Date: Sun, 2 Apr 2006 21:10:43 +0100 (BST) From: "Emmanuel Lecharny (JIRA)" To: dev@directory.apache.org Subject: [jira] Commented: (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 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12372854 ] Emmanuel Lecharny commented on DIRSERVER-169: --------------------------------------------- No time frame available right now :( We are busy on very time consuming tasks atm, and it's very difficult for us to find some spare time out of our spare time we spend on ADS:) However, I think that as soon as we have a fix for the concurrence problem we have on ADS, we will be able to spend some more extra time on a few bugs in the bug list, like your one. Another possibility is that we just get fed of working hard on hard stuff, and try to clear our mind buffers by fixing your problem, just to feel that we are usefull :) Don't be afraid to do some polling on us, that's just cool. > Incorrect SearchResult name and "compare" failure using CoreContextFactory > -------------------------------------------------------------------------- > > Key: DIRSERVER-169 > URL: http://issues.apache.org/jira/browse/DIRSERVER-169 > Project: Directory ApacheDS > 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 > Attachments: 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