[ http://issues.apache.org/jira/browse/DIRLDAP-87?page=comments#action_12364477 ]
Luke Taylor commented on DIRLDAP-87: ------------------------------------ Hi Emmanuel, Thanks for the response. My understanding of isRelative() is that it should return true unless the name in the result is from a referral and is a full URL, otherwise it should be relative to the "target context" (the context the search is performed in). There is some info on this in the Java tutorial: http://java.sun.com/products/jndi/tutorial/ldap/search/result.html Though that may not be correct :). In any case, the behaviour doesn't appear to be consistent. If I modify the test to use if(searchResult.isRelative()) { if(searchBase.length() > 0) { userDn.append(","); userDn.append(searchBase); } userDn.append(","); userDn.append(ctx.getNameInNamespace()); } The isRelative() method returns "true". In this case the name should be relative to "ou=people,dc=acegisecurity,dc=org", since I'm passing "ou=people" to the search method. However the name of the search result is "uid=bob,ou=people,dc=acegisecurity,dc=org". > Incorrect SearchResult name and "compare" failure using CoreContextFactory > -------------------------------------------------------------------------- > > Key: DIRLDAP-87 > URL: http://issues.apache.org/jira/browse/DIRLDAP-87 > Project: Directory LDAP > Type: Bug > 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
