[ http://issues.apache.org/jira/browse/DIRSERVER-169?page=all ]
Luke Taylor updated DIRSERVER-169:
----------------------------------
Attachment: DIRSERVER169TestCase.java
Ok. Here's an updated test.
I can't build the RC4 code since I'm running into issues with tools.jar as a
dependency (a maven problem with OS X, I believe), but I ran it against the RC3
jars.
The password comparison now appears to work if a string is used for the
attribute, but fails for a byte array.
The SearchResult name still appears to be wrong.
Thanks,
Luke.
> 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: 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
