NormalizationService is not handling correctly a Name with a comma followed by a space in it: for instance "text1, text2"

• Key: DIRSERVER-258
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Emmanuel Lecharny
• Reporter: Giamma
• Affects Version/s: pre-1.0
• Fix Version/s: 1.5.0

Description

In my custom partition I have organizations with various special characters in their name, for instance:
"text1=text2"
"text1 text2"
"text1,text2"
The 3 above all work fine.

But the following won't be normilized correctly:
"text1= text2"
"text2, text2"

They are normilized by NormalizationService.search or NormalizationService.hasEntry as this:
"text1= text2" --> "text1=text2"
"text2, text2" --> "text1,text2"

The space after the = or the , are skipped.
I think the code doing this is coming from antrl.
I tried using the latest 2.7.5 but the problem is still there.

I think the actual class with the bug is LLKParser.
I didn't download the code so i am not sure what's wrong.
I believe this is a regression as the same test case used to work with a previous
version of apache DS.

Let me know if you need anything more from me.

Comments

[Emmanuel Lecharny]

hi,

can you give us a full sample (ldif file or test case) ?

It will ease the debugging of this problem.

Thanks a lot !

[Giamma]

Well I am using my custom partition, which generates entries using some of our API to access our oracle DB, but I can give you a LDIF file with the organization who is having a problem.
I will attach the file.

the one with problems is:
dn: ou=Corporate Category\, Operations,bsiViewName=direct report view

The space after the "\," is somehow skipped.
So when I click on that entry, hasEntry will fails because it will try to look for:
"ou=corporate category\,operations,bsiViewName=direct report view"

In my code when I search for "corporate category\,operations" I will not find the organization.

[Alex Karasulu]

I tried real hard to reproduce this with a couple test cases to no avail. Giamma next time please see if you can attach a testcase, it would help save time in the future by perhaps isolating the problem. If I have a test case to reproduce the bug I can easily take care of it.

check the svn tab in this jira for the test cases added for trying to reproduce this issue

well I thought that I explained in details how to reproduce it.

Did you see the LDIF that was attached ?

May be the verion of the SW that you tested on, did not have the problem anymore.
I will test this again in the next version to see if I can reproduce it.

[Giamma]

ok I researched this a bit more.

I was not able to reproduce the problem in the default standard partition (ou=system). but the problem is still there.
your backend (org.apache.ldap.server.partition.impl.btree.jdbm.JdbmDirectoryPartition) is a bit more powerful and is able to hanlde the
lack of a space in the DN.

This is how I reproduced it.
1) Using an LDAP browser (like JXplorer), under ou=system, create a new organization (organizationalUnit) called "corporate category, operations"
2) the creating will work just fine
3) click on it with an LDAP browser. This will trigger in the LDAP server a call to DefaultDirectoryPartitionNexus.hasEntry.

If you look in here the DN being passed is:
ou=corporate category\,operations,ou=system
and not
ou=corporate category\, operations,ou=system

so again there is a missing space.

Now your backend is smart to find this entry even wthout the missing space, but I think this is a bug.
My backend (the custom partition that I wrote) is not smart enough to search without the space.
I could add an hack but it would have peformance consequences.

I think the parsing should do the right thing.

My 2 cents.

[Giamma]

A quick way to reproduce is by adding some code to NormalizationService.init().

You will see that the space after the "," is being stripped.
 

public void init( DirectoryServiceConfiguration factoryCfg, InterceptorConfiguration cfg ) throws NamingException
    {
        registry = factoryCfg.getGlobalRegistries().getAttributeTypeRegistry();
        NameComponentNormalizer ncn = new PerComponentNormalizer();
        parser = new DnParser( ncn );
        visitor = new ValueNormalizingVisitor( ncn );

        Name base = new LdapName("ou=test\\, test");
        base = parser.parse(base.toString());
        System.out.println(base);
    }

[Emmanuel Lecharny]

Ok, this is a clear bug in the DN parser.

However, fixing it right now is something quite complcated. We already have a plain new DNParser, which is supposed to be faster and - I hope - has some fix for problem like this one.

The problem is that switching from the actual parser to the new one is not a simple matter. We are thinking about it for 1.1.

I think that as soon as one can fetch something like "o=organization\, test" and get back "o=organization,test" without space, then you may consider it as half satisfactory. There is not a lot of people out there who use a ',' in a DN.

Not that it's not a serious bug, but this is the kind of bug we want to fix a little bit latter, because it's nor urgent.

However, thanks a lot for being so tenacious, and be sure that we are doing our best to deliver a fix soon !

[Emmanuel Lecharny]

I donwgraded the issue from Major to Minor, and set a due date to 1.1.

Of course, Minor doesn't mean we don't care. We just have to prioritize the fixes ;)

[Emmanuel Lecharny]

It has been fixed some times ago. I have tested the attached ldif file, and it seems that no space is missing

[Emmanuel Lecharny]

Closing all issues created in 2005 and before which are marked resolved