ApacheDS trunk: JDK1.4/unit test/normalisation issues

Web Server Talk > Web Servers reviews > Apache Server configuration support > Apache Directory Project > ApacheDS trunk: JDK1.4/unit test/normalisation issues

Pages (3): [1] 2 3 »

Last Thread Next Thread Next

ApacheDS trunk: JDK1.4/unit test/normalisation issues

Norbet Reilly

07-12-06 06:11 AM

Sorry, forgot to change subject before sending

On 7/12/06, Norbet Reilly <nrhope-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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/suppo
rt/HighestPrecedenceFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/suppo
rt/MaxValueCountFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/suppo
rt/MicroOperationFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/suppo
rt/MostSpecificProtectedItemFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/suppo
rt/MostSpecificUserClassFilterTest.java.bak
> ./apacheds/core/src/test/java/org/apache/directory/server/core/authz/suppo
rt/RestrictedByFilterTest.java.bak
> ./apacheds/core-unit/src/test/java/org/apache/directory/server/core/sp/Lda
pClassLoaderTest.java.bak
> ./mina/core/src/test/java/org/apache/mina/common/support/FutureTest.java.b
ak
> ./mina/core/src/test/java/org/apache/mina/transport/socket/nio/SocketBindT
est.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/LdifRead
erTest.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
>

[ Post a follow-up to this message ]