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
http://svn.apache.org/repos/asf/directory/apacheds/trunk-with-dependencies
or the latter combined with
https://svn.apache.org/repos/asf/directory/apacheds/branches/apacheds-mina2
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
week.
Feel free to join me on IRC if you need some quick help to build this
branch.
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
www.iktek.com
directory.apache.org
