[
http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12430804
]
Alex Karasulu commented on DIRSERVER-169:
-----------------------------------------
On commit revision 437255 I made it so SearchResult.isRelative() returns the
correct value. This will allow you to detect whether or not the search results
returned are relative names or absolute names. The core JNDI provider will
always return absolute names. Here's a link to svn for your convenience:
http://svn.apache.org/viewvc?view=rev&revision=437255
This fixes 1/2 of your issue. The second problem you're facing is the same as
DIRSERVER-715. Basically binary attributes in search filters are causing big
problems within ApacheDS. I'm going to try to fix this tomorrow night with
Emmanuel. Thanks for the solid test case Luke we really appreciate it.
> 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
