directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-169) Incorrect SearchResult name and "compare" failure using CoreContextFactory
Date Sun, 20 Aug 2006 19:38:15 GMT
    [ http://issues.apache.org/jira/browse/DIRSERVER-169?page=comments#action_12429291 ] 
            
Alex Karasulu commented on DIRSERVER-169:
-----------------------------------------

Luke if you could write a unit test case which starts ApacheDS and does some operations against
it to exactly isolate your problem I can get you a fix quickly.  Take a look at how to write
a unit test case from here as an example:

Here's one that does not startup ApacheDS networking but uses the core JNDI provider directly:

http://svn.apache.org/viewvc/directory/branches/apacheds/1.0/core-unit/src/test/java/org/apache/directory/server/core/jndi/CreateContextITest.java?revision=428079&view=markup

Here's a test case that starts up networking so you can hit the embedded apacheds through
SUN JNDI:

http://svn.apache.org/viewvc/directory/branches/apacheds/1.0/server-unit/src/test/java/org/apache/directory/server/ModifyRemoveTest.java?revision=430261&view=markup

If you could be so kind as to set up a test case in either of these areas depending on whether
or not you use ApacheDS JNDI or SUN JNDI providers I can fix this issue of yours very quickly.
 Plus I can add the test case to our codebase if you attach it as a patch (JIRA attachment)
using svn diff.

And yes if you worked against the current 1.0-RC4-SNAPSHOT'd branch that would be best for
us.  I want to make sure we're up to date and kill this bug of yours.

Thanks very much!


> 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: 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

        

Mime
View raw message