Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of aok123@bellsouth.net designates
 205.152.59.70 as permitted sender)
Message-ID: <43FA8402.6000809@bellsouth.net>
Date: Mon, 20 Feb 2006 22:07:46 -0500
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: dev@directory.apache.org
Subject: [ApacheDS] New issues with name parser 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Emmanuel,

I'm thinking some of the recent changes on the name parser may have 
introduced new problems.

These are really weird problems.  They happen only when running 
regression tests in maven within the server-unit module.  Yeah crazy.  
Basically to reproduce run "mvn -Dregression test" inside the 
apacheds/server-main module.  These are the tests that fail:

$ mvn -Dregressions test
[INFO] 
----------------------------------------------------------------------------
[INFO] Building ApacheDS Server Unit
....
T E S T S
-------------------------------------------------------
....
[surefire] Running org.apache.directory.server.AddObjectClassesToEntryTest
[surefire] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 0.113 sec 
<<<<<<<< FAILURE !!
[surefire] Running org.apache.directory.server.MiscTest
[surefire] Tests run: 7, Failures: 0, Errors: 7, Time elapsed: 0.177 sec 
<<<<<<<< FAILURE !!
[surefire] Running org.apache.directory.server.MatchingRuleCompareTest
[surefire] Tests run: 3, Failures: 0, Errors: 3, Time elapsed: 0.08 sec 
<<<<<<<< FAILURE !!

Now when these tests run inside eclipse there is no problem.  Here's 
what teh surefire report
looks like for these failures.  They are all pretty much the same trace:
========================================================================================================
o.a.d.shared.ldap.exception.LdapConfigurationException: Failed to 
normalize the suffix: ou=system
[Root exception is o.a.d.shared.ldap.exception.LdapInvalidNameException: 
Parser failure on name:
        ou=system
Antlr exception trace:
line 1:1: unexpected token: ou
        at 
o.a.d.shared.ldap.name.antlrNameParser.attributeTypeAndValue(antlrNameParser.java:192)
        at 
o.a.d.shared.ldap.name.antlrNameParser.nameComponent(antlrNameParser.java:120)
        at 
o.a.d.shared.ldap.name.antlrNameParser.name(antlrNameParser.java:69)
        at o.a.d.shared.ldap.name.DnParser.parse(DnParser.java:208)
        at o.a.d.shared.ldap.name.LdapName.<init>(LdapName.java:115)
        at 
o.a.d.server.core.configuration.DirectoryPartitionConfiguration.setSuffix(DirectoryPartitionConfiguration.java:203)
========================================================================================================

The suspect code is at 
o.a.d.server.core.configuration.DirectoryPartitionConfiguration.setSuffix(DirectoryPartitionConfiguration.java:203:

    /**
     * Sets the suffix of the {@link DirectoryPartition}.
     */
    protected void setSuffix( String suffix ) throws NamingException
    {
        suffix = suffix.trim();
        try
202:  {
203:        new LdapName( suffix );       <<<<<<<<================== HERE!!!
204:  }
        catch ( NamingException e )
        {
            throw new LdapConfigurationException( "Failed to normalize 
the suffix: " + suffix, e );
        }
        this.suffix = suffix;
    }

This is crazy though because how the heck is the parser failing on 
"ou=system" and succeeding on all test cases I cannot understand.  I 
think I'm loosing my mind on this one this is why I need a second 
opinion.  Please advise.

Thanks,
Alex