[ https://issues.apache.org/jira/brow...ls:all-tabpanel ]

Alex Karasulu updated DIRSERVER-169:
------------------------------------

Affects Version/s: 1.0.2
1.0
1.0-RC4
1.0-RC3
1.0-RC2
1.0-RC1
pre-1.0

I don't think it's worth making this change for 1.0.x considering the possib
le destablization that may result.  It's best that we fix this issue in the 
1.5.x branch where we have the freedom to refactor for it.

> Incorrect SearchResult name and "compare" failure using CoreContextFactory
> --------------------------------------------------------------------------
>
>                 Key: DIRSERVER-169
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-169
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.2, 1.0.1, 1.5.0, 1.0, 1.0-RC4, 1.0-RC3, 1.0-RC2, 
1.0-RC1, pre-1.0
>         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.5.1, 1.0.2
>
>         Attachments: DIRSERVER169TestCase.java, LdapTestServer.java, TestC
ase.zip
>
>
> Attached is a test case following on from my post a while back to the mail
ing list, viz:
> My setup is like this:
> I have a simple DIT with a root "dc=acegisecurity,dc=org". This has two su
bcontexts "ou=people" and "ou=groups" for my users and roles respectively. W
hen 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 fo
llows:
>     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 dir
ectory, 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=or
g"
> whereas with the full server (or OpenLDAP) I get
> "uid=bob"
> as expected. This then unfortunately leads to an attempt to bind with an a
n unknown DN which causes the infinite recursion problem.
> 2. Performing "compare" operations. I had problems with this before, as re
ported in
> http://issues.apache.org/jira/browse/DIRLDAP-77
> but this now works with the full server, thanks to Emmanuel's speedy response. Run
ning the same search code against a context obtained from CoreContextFactory fails h
owever. A compare is never performed and the search returns an empty enumeration. Is
 th
ere 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-bi
nary attributes.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[ Post a follow-up to this message ]