directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norbet Reilly" <nrh...@gmail.com>
Subject Re: ApacheDS trunk: JDK1.4/unit test/normalisation issues
Date Wed, 12 Jul 2006 04:10:03 GMT
On futher investigation, I may have contributed to the normalisation
problems as I had commented out the normalization service in the dim
distant past (as my interest is primarily using ApacheDS as custom
partition container).

Will comment it back in and uncomment my adhoc .normalise() calls and
report back

On 7/12/06, Norbet Reilly <nrhope@gmail.com> wrote:
> 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
> >
>

Mime
View raw message