Norbet Reilly a écrit :
Hi All,
Hi Norbet
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...
Sorry about that ...
I use JDK1.4 (still the intended target platform, correct ?)
Correct. But remember you need a JDK 5 to compile the code. This is
mandatory for Mina. However, the server should run with jdk 1.4
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.
I think it has been fixed ?
Another was the LDAP class loader seems to
refer to a JDK.1.5 compiled class.
uh? Do we have a classloader?
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.
Yeah, this was a major difference intrroduced for RC4
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.
(I think you fixed this as stated in one of your following mail)
So my questions are:
1. JDK 1.4 is still the target platform, correct?
yep
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.
(fixed, as stated in your next mail?)
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.
Do you still have pbs with unit tests?
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?
Well, trunk should work, but we are currently finishing a huge fixing
session in optimization-branch. It will be merged soon in trunk, and the
branch will be removed.
1.0 branch has not moved a lot.
Sorry if I sound a bit grumpy, the update led to a very late night.
np, I'm grumpy all the time :)
Any opinions gratefully accepted...
We are currently trying to fix the mess ... We have been a little bit
too busy to be able to stabilize some parts of the server.
Sorry about that...
Emmanuel
