[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12431044 ] Luke Taylor commented on DIRSERVER-169: ---------------------------------------
Great! Thanks for the fix(es). Look forward to the next release. > 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.1.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
