Issue Details (XML | Word | Printable)

Key: DIRSERVER-806
Type: Bug Bug
Status: Reopened Reopened
Priority: Minor Minor
Assignee: Emmanuel Lecharny
Reporter: Stefan Zoerner
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Directory ApacheDS

No continuation references for referrals returned for some search filters

Created: 27/Dec/06 03:27 PM   Updated: 26/May/07 07:09 AM
Return to search
Component/s: core
Affects Version/s: 1.0.1, 1.0
Fix Version/s: 1.0.3

Time Tracking:
Not Specified

File Attachments:
  Size
Java Source File Licensed for inclusion in ASF works ContinuationTest.java 2006-12-27 03:33 PM Stefan Zoerner 4 kB
Environment:
* ApacheDS 1.0.1 (SNAPSHOT)
* Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
* Windows XP Professional SP2


 Description  « Hide
I have created a referral entry below the example partition like this:

dn: cn=theReferral,dc=example,dc=com
objectclass: top
objectClass: referral
objectClass: extensibleObject
cn: theReferral
ref: ldap://someHost:389/cn=somewhere

Afterwards I have performed some searches in order to check whether ApacheDS returns a search result continuation reference. I used JNDI and set Context.REFERRAL to "throw" in order to check whether I get a ReferralException.

Case 1:
Base: dc=example,dc=com
Filter: (objectClass=*)
Scope: sub

=> ApacheDS delivers a continuation reference with the search result. I get an exception at the client.

Case 2:
Base: dc=example,dc=com
Filter: (cn=Nick Cave)
Scope: sub

=> Other than expected, ApacheDS does not deliver a continuation reference with the search result. No exception occurs.

Note that the only change is the filter expression.

I have created a JUnit testcase to demonstrate the situation. It has been successfully tested with other Directory servers (OpenLDAP, IBM, Sun). I'll attach it soon.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Stefan Zoerner added a comment - 27/Dec/06 03:33 PM
Here is a JUnit testcase which uses JNDI to demonstrate the problem described in this issue. It contains to tests and passes completely with the following servers:

* Sun Java System Directory Server 5.2
* IBM Tivoli Directory Server 6.0
* OpenLDAP 2.3

With ApacheDS 1.0.1, one of the two tests (testSimpleContinuationWithCnFilter) fails, no referral is returned.

Emmanuel Lecharny added a comment - 25/Jan/07 04:21 PM
To be fixed in 1.0.1 and 1.5.0

Emmanuel Lecharny added a comment - 12/Feb/07 06:33 PM
The problem is that the current server doe snot natively handle such searches for refferal : you have to add the Context.REFERRAL=throw property in order to get a referral exception. The current default implementation is to ignore the referral.

If one add this property to the request, both tests are passing.

I guess that we should change this behavior to default to THROW instead of IGNORE.

Stefan Zoerner added a comment - 12/Feb/07 07:03 PM
Emmanuel, thanks for your investigations! Do you mean that it is sufficient to change the configuration within server.xml?
Something like this?

...
<bean id="environment" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
    <property name="properties">
      <props>
        <prop key="java.naming.security.authentication">simple</prop>
        <prop key="java.naming.security.principal">uid=admin,ou=system</prop>
        <prop key="java.naming.security.credentials">******</prop>
        <prop key="java.naming.referral">throw</prop>
        ...

I'll try this out. Perhaps it is an option for my customer to simple configure the server that way.

Emmanuel Lecharny added a comment - 12/Feb/07 07:17 PM
Stefan, this is so good to work with smart people :) I wasn't even aware of such a property in the configuration file !

Ok, I can't guarantee that it will solve the problem, but maybe. Give it a try and give us some feedback !

Alex Karasulu added a comment - 13/Feb/07 01:53 AM
RE changing the default to THROW instead of IGNORE:

(1) is this the expected default for JNDI Providers?

(2) what side effects do we expect to see if we do this?

Yes and try mucking with the parameter in the configuration file :).

Stefan Zoerner added a comment - 13/Feb/07 07:53 PM
Unfortunately, simply adding the parameter in the server.xml does not cause the test case to pass.

Please note that this is a problem which currently blocks blocks both 1.0.x and 1.5.x from passing the STANDARD profile of the Open Group Certification. But because the 1.0 is certified for the BASE profile only, this issue is not a blocker for a 1.0.1 release. The latter would still be certified with the same level as the 1.0.0 (which obviously is expected by our users), because it can pass all relevant tests, without fixing this issue.

Emmanuel Lecharny added a comment - 14/Feb/07 03:17 PM
Postponed to 1.0.2. This bug is not serious (we can live with it for a little while), but fixing it is quite complicated.

The idea is to release the 1.0.1 version now, so that users can have a better version (1.0.0 has serious issues that we can't live with).

Emmanuel Lecharny added a comment - 27/Mar/07 11:48 PM
I may have fixed this issue in 1.0.2 :
http://svn.apache.org/viewvc?view=rev&rev=523116
and the test :
http://svn.apache.org/viewvc?view=rev&rev=523115

I hope this is correct !

Emmanuel Lecharny added a comment - 28/Mar/07 10:37 AM
Ok, after more investigation this morning ( the patch has been committed yesturday evening, 2 am, and I was too tired to confirm the fix), I saw that in 1.5.0, the code has been fixed. I just forgot to backport it to 1.0.2, so I guess it was a corrct patch because I fixed it twice in the same way :)

Marked as resolved, unless Stefan disagree.

Stefan Zoerner added a comment - 15/May/07 07:24 PM
Unfortunately, the method testSimpleContinuationWithCnFilter of the provided JUnit test still fails with the 1.0.2-SNAPSHOT.

Emmanuel Lecharny added a comment - 26/May/07 07:09 AM
As the 1.0.2 release has been issued, push this bug to 1.0.3