directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: stability of AD trunk
Date Thu, 27 Nov 2008 08:38:58 GMT
Norval Hope wrote:
> Hi Emmanuel,
Hi Norval,
> I've re-encountered a long standing problem with my AD < 1.5 version
> of the code, due to the LDAP codec's handling of moderately complex
> search filters (more below). However, I'm not having any luck getting
> either vanilla
> or the latter combined with
> working. I get miriad different failures, sometimes the "mvn install"
> itself fails and sometimes I'm able to run
> installers\apacheds-noarch\apacheds.bat successfully but can't bind to
> the server because of an NPE due to some problem with the referral
> interceptor (no referral manager is found).
we have a problem with trunk, the ReferralInterceptor is not present in 
the server.xml, leading to some NPE. This will be fixed in 1.5.5.

We also had some failures in ads-mina2 due to some bad code which as 
also been fixed a couple of days ago.

I'm sorry that it has become a bumpy road lately, I think we are back on 
a easier path now.
> I have, of course, being doing "mvn clean" and removing my repository
> but have had no joy. I just wanted to know which combination you'd
> recommend I focus on for the moment, I presume trunk-with-dependencies
> + apacheds-mina2  is working for you at the moment, right? Or is the
> vanilla trunk working for you at the moment and my problems somehow
> specific to my env?
I'm working on the ads-mina2 branch, as we will migrate to MINA 2 as 
soon as we can use a MINA 2 jar, which takes longer than expected. Sadly 
MINA 2.0.0-M3 was unusable for our need, and cutting a release in this 
side project takes some time. We are working on it, and it will be done 
in a week, I think. In the mean time, I must admit that every important 
modification is done in the branch, and that I'm expecting to merge next 

Feel free to join me on IRC if you need some quick help to build this 
> At any rate the problem(s) I had were all caused to trying to submit a
> fairly simple search:
> "(&(objectClass=nisNetgroup)(|(nisNetGroupTriple=a*a)(nisNetGroupTriple=\28*,acc1,*\29)))".
> I'm not able to verify which of these problems apply to the current
> trunk but will list them for the moment anyway:
>   1. The ldap codec had a serious bug parsing seach filters, so that
> the search above was mangled into
> "(&(objectClass=nisNetgroup)(|(nisNetGroupTriple=a*a))(nisNetGroupTriple=\28*,acc1,*\29))"
> (notice how the OR was truncated after the first assertion) by the
> time the request arrived to SearchHandler.messageReceived(). The
> problem is due to the codec's parsing of the *s and actually affects
> all nested ORs and ANDs. I have attached the patch but wanted to
> reproduce the problem against the most up to date code before raising
> a JIRA etc.
You can raise a JIRA, wze didn't modified this part of the code since 
... years ?
>   2. There were multiple NPE problems, one was because
> nisNetGroupTriple has no equality matching rule defined (even in the
> official RFC as best I can tell), and hence no normalizer could be
> found in SubstringEvaluator.
> Can you please:
>   1. try submitting the search filter above to your working server so
> I can get a handle on whether any of these problems exist in the trunk
> code
Sure, but can you fill a JIRA and attach the patch ?
>   2. guide me as to which version of the project to checkout (vanilla
> trunk or trunk + apacheds-mina2) and / or how you'd recommend me
> getting any patches (if they're required) to you in a way that won't
> waste your time.
from now on, if you want to test the bleeding hedge version, checkout 
the ads-mina2 branch, with the latest MINA2 trunk. It should do the 
trick. Against, I'm expecting a MINA release really soon, but we have 
still 8 issues pending in MINA, and with the 72 hours latence when a 
vote is called, I don't expect MINA 2 to be release before the end of 
next week.

Hope it helps...
> Thanks,
> Norval

cordialement, regards,
Emmanuel L├ęcharny

View raw message