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 nrhope@gmail.com designates
 64.233.162.198 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=G4xtGLckKHIH2Km0pIC4nTW1zfajtlQrfh6+MLcWhD2cp5fWSfnzRQAkCKllYBQa5P2S/R/LyBDKk/dv8jbzUAgNg3e1R6w801BKTsBJrP7R9m9yvkU4ueEOzvJ3oVKlZOWBN9VxF52/+2BI3WdmnmHxXiiujYoOkRjbKL/1jm4=
Message-ID: <f275eef10607111920s61e77f1cv709b4bc7d040f9d@mail.gmail.com>
Date: Wed, 12 Jul 2006 12:20:28 +1000
From: "Norbet Reilly" <nrhope@gmail.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: ApacheDS trunk: JDK1.4/unit test/normalisation issues
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Sorry, forgot to change subject before sending

On 7/12/06, Norbet Reilly <nrhope@gmail.com> wrote:
> Hi All,
>
> I haven't done an update to the latest SVN trunk for a while, so I
> thought I'd try one and see if I could take advantage of the speed
> improvements and enhanced LDIF reader support I've been reading about.
> Unfortunately things didn't go so smoothly...
>
> I use JDK1.4 (still the intended target platform, correct ?) as as
> with all of the updates I've done over the last six months or so,
> there were a number of build problems which I had to hack around. Two
> which I can remember were that the StringTools.DEFAULT_CHARSET_JDK_1_5
> constant can't be evaluated under JDK1.4 as it is assigned to a
> JDK1.5-specific method. Another was the LDAP class loader seems to
> refer to a JDK.1.5 compiled class.
>
>  After fixing these I then saw a whole raft of unit test failures and
> decided there wasn't going to be time to investigate/resolve them all,
> the list is as follows:
>
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/HighestPrecedenceFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MaxValueCountFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MicroOperationFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MostSpecificProtectedItemFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/MostSpecificUserClassFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/support/RestrictedByFilterTest.java.bak
> ./apacheds/core-unit/src/test/java/org/apache/directory/server/core/sp/LdapClassLoaderTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/common/support/FutureTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/transport/socket/nio/SocketBindTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/transport/vmpipe/VmPipeBindTest.java.bak
> ./shared/ldap/src/test/java/org/apache/directory/shared/ldap/ldif/LdifReaderTest.java.bak
>
> After moving these out of the way I had a working JDK1.4 build and
> needed to refactor my code to remove all LdapName refs and replace a
> number javax.naming.Name with LdapDN references: which was fine as I'd
> expected to need to do this work.
>
> However, when I attempted a sanity check reading a small LDIF file at
> ApacheDS start-up I encountered the most worrying set of problems. In
> about ten different places during start-up the core wasn't internally
> able to resolve the system partition (ou=system), as
> DefaultDirectoryPartitionNexus.getBackend(LdapDN) expects the provided
> DN to be normalised (<oid>=value), but was given an unormalised DN. At
> this stage I was quite a few hours into the update and decided to just
> hack in any number of .normalise()s to see if I could get the system
> to start-up.
>
> So my questions are:
>  1. JDK 1.4 is still the target platform, correct?
>  2. I know updating to the trunk usually involves an element of risk,
> but my experiences with this upgrade tend to suggest that the codebase
> currently has some pretty deep-running issues re LdapDN normalisation.
> It's possible that all the problems I saw were due to importing LDIF,
> but I strongly suspect otherwise. I'll do some other testing before
> rolling back to the snapshot I was using previously.
>  3. Am I the only one seeing these problems with unit
> tests/normalisation on the trunk? If not, is there a point in time
> when the stability of the trunk is expected to be restored.
>  4. I tried a few weeks back to move from the trunk back to the 1.0
> branch (which I'd prefer to use ultimately) but had the same JDK1.4
> compatibility issues reported above, so didn't want to invest a lot of
> time in back-porting my customisations until it looked closer to being
> frozen.
>  5. Which codebase would the comitters advise me to concentrate on,
> should I concentrate exclusively on the 1.0 branch and ignore the
> trunk for a while?
>
> Sorry if I sound a bit grumpy, the update led to a very late night.
>
> Any opinions gratefully accepted...
>
> Thanks
>