LdapName.getPrefix(int) does not return prefix.

• Key: DIRSERVER-191
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Critical
• Assignee: Alex Karasulu
• Reporter: Jacob S. Barrett
• Component/s: ldap
• Fix Version/s: 1.5.0

Description

The JavaDoc for javax.naming.Name.getPrefix(int) [1] states that it returns "a name consisting of the components at indexes in the range [0,posn)." The implementation in org.apache.ldap.common.name.LdapName returns [size() - posn, size()). This is a suffix starting from the right like the getSuffix(int) which is a suffix from from the left. The correct implementation should return the prefix from the left to the specified position. Attached is the appropiate patch for LdapName.java and LdapNameTest.java.

References:
1) http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/Name.html#getPrefix(int)

Patch:
Index: shared/ldap/trunk/common/src/test/org/apache/ldap/common/name/LdapNameTest.java
===================================================================
--- shared/ldap/trunk/common/src/test/org/apache/ldap/common/name/LdapNameTest.java (revision 158112)
+++ shared/ldap/trunk/common/src/test/org/apache/ldap/common/name/LdapNameTest.java (working copy)
@@ -545,10 +545,10 @@
         Name l_name =
             m_parser.parse( "cn=HomeDir,cn=John,ou=Marketing,ou=East" ) ;
         assertEquals( "", l_name.getPrefix( 0 ).toString() ) ;
- assertEquals( "ou=East", l_name.getPrefix( 1 ).toString() ) ;
- assertEquals( "ou=Marketing,ou=East",
+ assertEquals( "cn=HomeDir", l_name.getPrefix( 1 ).toString() ) ;
+ assertEquals( "cn=HomeDir,cn=John",
             l_name.getPrefix( 2 ).toString() ) ;
- assertEquals( "cn=John,ou=Marketing,ou=East",
+ assertEquals( "cn=HomeDir,cn=John,ou=Marketing",
             l_name.getPrefix( 3 ).toString() ) ;
         assertEquals( "cn=HomeDir,cn=John,ou=Marketing,ou=East",
             l_name.getPrefix( 4 ).toString() ) ;
Index: shared/ldap/trunk/common/src/java/org/apache/ldap/common/name/LdapName.java
===================================================================
--- shared/ldap/trunk/common/src/java/org/apache/ldap/common/name/LdapName.java (revision 158112)
+++ shared/ldap/trunk/common/src/java/org/apache/ldap/common/name/LdapName.java (working copy)
@@ -327,7 +327,7 @@
     public Name getPrefix( int a_posn )
     {
         ArrayList list = new ArrayList();
- list.addAll( m_list.subList( size() - a_posn, size() ) );
+ list.addAll( m_list.subList( 0, a_posn ) );
         return new LdapName( list ) ;
     }
 

Comments

[Alex Karasulu]

Let's put this into 0.9 release.

[Alex Karasulu]

Jacob I could really use a patch file attachment and a JUnit test again. Also would be nice to show how a JDK Name implementation behaves in comparison so we can see what's happening in the test case. If you can get this to me soon I can cut the 0.9 release tarballs for all to test. Thanks.

[Jacob S. Barrett]

The patch fixes the backwards getSuffix() call and the attached file is JUnit that compare LdapName against the one in JDK 1.5. The JUnit must be compiled and executed with the rt.jar from JDK 1.5.

[Jacob S. Barrett]

The patch fixes a bug introduced by fixing the getSuffix() in the previous patch. In addition there is a JUnit to test this patch.

[Alex Karasulu]

The bug with getSuffix is way serious and it drills down deep. We've worked around the bug it seems. Regardless 4 major classes depend on getSuffix working the wrong way:

org.apache.ldap.server.exceptionorg.apache.ldap.server.exception.ExceptionService
org.apache.ldap.server.jndi.ServerContext
org.org.apache.ldap.server.db.jdbm.JdbmDatabase
org.apache.ldap.seorg.apache.ldap.server.operational.OperationalAttributeService

This is going to require some serious testing to make sure we are not totally messing up the server. Instead of taking this on before the next feature release I will leave it for 0.9.1 and handle it properly then. Currently it is not producing a negative effect in the server so it should be ok.

[Alex Karasulu]

Increasing criticality - making sure I'm going to take care of this right after the 0.9 release.

[Alex Karasulu]

Jacob points out DIRLDAP-112 supercedes this on.

I guess this issue is not resolved right now? I'm reopening...

[Emmanuel Lecharny]

This issue has been solved a long time ago, but when?

Tests have been added into LdapDNTest class.

[Emmanuel Lecharny]

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