[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12429210 ] Luke Taylor commented on DIRSERVER-169: ---------------------------------------
I don't think there are any Acegi specifics, apart from the DIT name. There's a JUnit class which contains two test methods, demonstrating each of the two issues, and a separate class which contains the embedded server. Did you have a problem running it? I haven't checked that it still compiles against the latest apache-ds code. The report was pre-1.0, but we're currently using 1.0-RC1 as a dependency and still have problems with that. > 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 > 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
