You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Norval Hope <nr...@gmail.com> on 2008/11/27 04:02:46 UTC
stability of AD trunk
Hi Emmanuel,
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).
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?
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.
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
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.
Thanks,
Norval
Re: stability of AD trunk
Posted by Norval Hope <nr...@gmail.com>.
Thanks for the feedback.
On Thu, Nov 27, 2008 at 7:38 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
snip
> 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.
snip
Sure - I'm glad it wasn't a problem with my environment only.
>
> 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.
No probs, I thought looking at the dates of the last modifications
that apacheds-mina2 was the right branch, but if ads-mina2 is the
right one then I'll take note.
>
> 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.
Sure, I'll raise the JIRA and submit the patch but will most probably
wait until you're happy with the trunk again before looking at the
issue in detail again.
>
> You can raise a JIRA, wze didn't modified this part of the code since ...
> years ?
Will do. Yeah I'm pretty sure the issue is old too as I ran into it a
few times before but never got to the bottom of exactly where the
problem was and worked around the need for the nested filter instead.
However, when using nisNetGroup my options are much more limited.
> Hope it helps...
Thanks, does help indeed! Get some sleep!
Cheers
Re: stability of AD trunk
Posted by Norval Hope <nr...@gmail.com>.
Thanks, will give it a try out tomorrow!
On Thu, Nov 27, 2008 at 9:33 PM, Pierre-Arnaud Marcelot <pa...@marcelot.net> wrote:
> Hi,
>
> On Thu, Nov 27, 2008 at 9:38 AM, Emmanuel Lecharny <el...@gmail.com>
> wrote:
>>
>> 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.
>
> I fixed it, so the trunk is in a "more" stable state.
> At least, one is able to launch the server after a clean build.
>
> Regards,
> Pierre-Arnaud
>
>
Re: stability of AD trunk
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi,
On Thu, Nov 27, 2008 at 9:38 AM, Emmanuel Lecharny <el...@gmail.com>wrote:
> 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.
I fixed it, so the trunk is in a "more" stable state.
At least, one is able to launch the server after a clean build.
Regards,
Pierre-Arnaud
Re: stability of AD trunk
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: stability of AD trunk
Posted by Norval Hope <nr...@gmail.com>.
Thanks for the info. Once I'm able to run with NIS enabled I'll be
able to confirm that the issue is 100% gone in the trunk code, will
try working around the unit test NPE using your advice on Mon. Raised
a JIRA as you probably noticed.
Cheers
On Fri, Nov 28, 2008 at 10:28 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Norval Hope wrote:
>>
>> I've also been trying to test that the filter evaluates correctly by
>> creating a few nisNetgroups and ensuring the right search results are
>> returned, as the NPEs I saw with the old version were in the filter
>> evaluation code. This required activating the nis.schema which I
>> attempted to achieve by commenting out nis in
>> apacheds\bootstrap-partition\pom.xml as follows:
>>
>> <plugin>
>> <groupId>org.apache.directory.server</groupId>
>> <artifactId>apacheds-bootstrap-plugin</artifactId>
>> <configuration>
>> <disabledSchemas>
>> <!--<disabledSchema>nis</disabledSchema>--> !!!!!!!!!!
>> <disabledSchema>krb5kdc</disabledSchema>
>>
>
> <snip/>
>>
>> however after doing that "mvn install" fails as follows:
>>
>
> <snip/>
>>
>> Running org.apache.directory.server.core.suites.SchemaISuite
>> javax.naming.NamingException [Root exception is
>> java.lang.NullPointerException]
>> at
>> org.apache.directory.server.core.jndi.JndiUtils.wrap(JndiUtils.java:40)
>> at
>> org.apache.directory.server.core.jndi.ServerDirContext.modifyAttributes(ServerDirContext.java:260)
>> at
>> org.apache.directory.server.core.jndi.ServerDirContext.modifyAttributes(ServerDirContext.java:242)
>> at
>> org.apache.directory.server.core.schema.SchemaPersistenceIT.enableSchema(SchemaPersistenceIT.java:149)
>> at
>> org.apache.directory.server.core.schema.SchemaPersistenceIT.testAddAttributeTypePersistence(SchemaPersistenceIT.java:81)
>>
>
> This is a side effect : when you remove the <disable nis> line in the
> apacheds-bootstrap pom.xml file, this schema is enabled. Now the tests start
> with :
>
> public void testAddAttributeTypePersistence() throws Exception
> {
> try
> {
> enableSchema( "nis" );
>
> which won't work, of course.
>
> But I must admit that this NPE is obviously a mistake. We should simply
> return from this method silently if the schema is already enabled.
>
> Can you fill a JIRA for this ? It should be easy to fix.
>
> <snip/>
>>
>> On Fri, Nov 28, 2008 at 2:36 PM, Norval Hope <nr...@gmail.com> wrote:
>>
>>>
>>> Hi,
>>>
>
> <snip/>
>>>
>>> Now that I can run the trunk code, I have been able to verify that
>>> neither the codec parsing problem nor the NPEs occur for it. Sorry for
>>> the distraction - like you I thought the codec hadn't changed much for
>>> a long time and therefore felt fairly sure that the problem would
>>> still be around on the trunk. The problem I saw related to the 0x30
>>> SEQUENCE around the the substring assertion components, which was on
>>> the top of the stack when SearchRequest.unstackFilters() was called
>>> but this method
>>>
>>> Here is the output from my test
>>>
>>> (filter="(&(objectClass=nisNetgroup)(|(nisNetGroupTriple=a*a)(nisNetGroupTriple=\28*,acc1,*\29)))")
>>> which includes the PDU:
>>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>>> (org.apache.directory.shared.ldap.codec.TwixDecoder:114) DEBUG -
>>> Decoding the PDU :
>>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>>> (org.apache.directory.shared.ldap.codec.TwixDecoder:128) DEBUG - 0x30
>>> 0x81 0xAE 0x02 0x01 0x06 0x63 0x81 0x8B 0x04 0x09 0x6F 0x75 0x3D 0x73
>>> 0x79 0x73 0x74 0x65 0x6D 0x0A 0x01 0x02 0x0A 0x01 0x00 0x02 0x01 0x00
>>> 0x02 0x01 0x00 0x01 0x01 0x00 0xA0 0x60 0xA3 0x1A 0x04 0x0B 0x6F 0x62
>>> 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x04 0x0B 0x6E 0x69 0x73
>>> 0x4E 0x65 0x74 0x67 0x72 0x6F 0x75 0x70 0xA1 0x42 0xA4 0x1B 0x04 0x11
>>> 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72 0x69
>>> 0x70 0x6C 0x65 0x30 0x06 0x80 0x01 0x61 0x82 0x01 0x61 0xA4 0x23 0x04
>>> 0x11 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72
>>> 0x69 0x70 0x6C 0x65 0x30 0x0E 0x80 0x01 0x28 0x81 0x06 0x2C 0x61 0x63
>>> 0x63 0x31 0x2C 0x82 0x01 0x29 0x30 0x0D 0x04 0x0B 0x6F 0x62 0x6A 0x65
>>> 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0xA0 0x1B 0x30 0x19 0x04 0x17 0x32
>>> 0x2E 0x31 0x36 0x2E 0x38 0x34 0x30 0x2E 0x31 0x2E 0x31 0x31 0x33 0x37
>>> 0x33 0x30 0x2E 0x33 0x2E 0x34 0x2E 0x32
>>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>>> (org.apache.directory.shared.ldap.codec.TwixDecoder:135) DEBUG -
>>> Decoded LdapMessage : LdapMessage
>>> message Id : 6
>>> Search Request
>>> Base Object : 'ou=system'
>>> Scope : whole subtree
>>> Deref Aliases : never Deref Aliases
>>> Size Limit : no limit
>>> Time Limit : no limit
>>> Types Only : false
>>> Filter : '(&(objectClass=nisNetgroup)(|(a*a)((*,acc1,*))))'
>>> Attributes : objectclass
>>> Control
>>> Control type : '2.16.840.1.113730.3.4.2'
>>> Criticality : 'false'
>>>
>>> Note that the extra ()s around "((*,acc1,*))" aren't actually a
>>> problem but rather due to the toString() not requoting the \28 and \29
>>> (which was one of the fixes in my patch for DIRSERVER-1247).
>>>
>
> I will apply this part of the patch, then.
>
> So you confirm this is not any more a problem in the ads-mina2 branch ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: stability of AD trunk
Posted by Emmanuel Lecharny <el...@gmail.com>.
Norval Hope wrote:
> I've also been trying to test that the filter evaluates correctly by
> creating a few nisNetgroups and ensuring the right search results are
> returned, as the NPEs I saw with the old version were in the filter
> evaluation code. This required activating the nis.schema which I
> attempted to achieve by commenting out nis in
> apacheds\bootstrap-partition\pom.xml as follows:
>
> <plugin>
> <groupId>org.apache.directory.server</groupId>
> <artifactId>apacheds-bootstrap-plugin</artifactId>
> <configuration>
> <disabledSchemas>
> <!--<disabledSchema>nis</disabledSchema>--> !!!!!!!!!!
> <disabledSchema>krb5kdc</disabledSchema>
>
<snip/>
> however after doing that "mvn install" fails as follows:
>
<snip/>
> Running org.apache.directory.server.core.suites.SchemaISuite
> javax.naming.NamingException [Root exception is java.lang.NullPointerException]
> at org.apache.directory.server.core.jndi.JndiUtils.wrap(JndiUtils.java:40)
> at org.apache.directory.server.core.jndi.ServerDirContext.modifyAttributes(ServerDirContext.java:260)
> at org.apache.directory.server.core.jndi.ServerDirContext.modifyAttributes(ServerDirContext.java:242)
> at org.apache.directory.server.core.schema.SchemaPersistenceIT.enableSchema(SchemaPersistenceIT.java:149)
> at org.apache.directory.server.core.schema.SchemaPersistenceIT.testAddAttributeTypePersistence(SchemaPersistenceIT.java:81)
>
This is a side effect : when you remove the <disable nis> line in the
apacheds-bootstrap pom.xml file, this schema is enabled. Now the tests
start with :
public void testAddAttributeTypePersistence() throws Exception
{
try
{
enableSchema( "nis" );
which won't work, of course.
But I must admit that this NPE is obviously a mistake. We should simply
return from this method silently if the schema is already enabled.
Can you fill a JIRA for this ? It should be easy to fix.
<snip/>
> On Fri, Nov 28, 2008 at 2:36 PM, Norval Hope <nr...@gmail.com> wrote:
>
>> Hi,
>>
<snip/>
>> Now that I can run the trunk code, I have been able to verify that
>> neither the codec parsing problem nor the NPEs occur for it. Sorry for
>> the distraction - like you I thought the codec hadn't changed much for
>> a long time and therefore felt fairly sure that the problem would
>> still be around on the trunk. The problem I saw related to the 0x30
>> SEQUENCE around the the substring assertion components, which was on
>> the top of the stack when SearchRequest.unstackFilters() was called
>> but this method
>>
>> Here is the output from my test
>> (filter="(&(objectClass=nisNetgroup)(|(nisNetGroupTriple=a*a)(nisNetGroupTriple=\28*,acc1,*\29)))")
>> which includes the PDU:
>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>> (org.apache.directory.shared.ldap.codec.TwixDecoder:114) DEBUG -
>> Decoding the PDU :
>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>> (org.apache.directory.shared.ldap.codec.TwixDecoder:128) DEBUG - 0x30
>> 0x81 0xAE 0x02 0x01 0x06 0x63 0x81 0x8B 0x04 0x09 0x6F 0x75 0x3D 0x73
>> 0x79 0x73 0x74 0x65 0x6D 0x0A 0x01 0x02 0x0A 0x01 0x00 0x02 0x01 0x00
>> 0x02 0x01 0x00 0x01 0x01 0x00 0xA0 0x60 0xA3 0x1A 0x04 0x0B 0x6F 0x62
>> 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x04 0x0B 0x6E 0x69 0x73
>> 0x4E 0x65 0x74 0x67 0x72 0x6F 0x75 0x70 0xA1 0x42 0xA4 0x1B 0x04 0x11
>> 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72 0x69
>> 0x70 0x6C 0x65 0x30 0x06 0x80 0x01 0x61 0x82 0x01 0x61 0xA4 0x23 0x04
>> 0x11 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72
>> 0x69 0x70 0x6C 0x65 0x30 0x0E 0x80 0x01 0x28 0x81 0x06 0x2C 0x61 0x63
>> 0x63 0x31 0x2C 0x82 0x01 0x29 0x30 0x0D 0x04 0x0B 0x6F 0x62 0x6A 0x65
>> 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0xA0 0x1B 0x30 0x19 0x04 0x17 0x32
>> 0x2E 0x31 0x36 0x2E 0x38 0x34 0x30 0x2E 0x31 0x2E 0x31 0x31 0x33 0x37
>> 0x33 0x30 0x2E 0x33 0x2E 0x34 0x2E 0x32
>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>> (org.apache.directory.shared.ldap.codec.TwixDecoder:135) DEBUG -
>> Decoded LdapMessage : LdapMessage
>> message Id : 6
>> Search Request
>> Base Object : 'ou=system'
>> Scope : whole subtree
>> Deref Aliases : never Deref Aliases
>> Size Limit : no limit
>> Time Limit : no limit
>> Types Only : false
>> Filter : '(&(objectClass=nisNetgroup)(|(a*a)((*,acc1,*))))'
>> Attributes : objectclass
>> Control
>> Control type : '2.16.840.1.113730.3.4.2'
>> Criticality : 'false'
>>
>> Note that the extra ()s around "((*,acc1,*))" aren't actually a
>> problem but rather due to the toString() not requoting the \28 and \29
>> (which was one of the fixes in my patch for DIRSERVER-1247).
>>
I will apply this part of the patch, then.
So you confirm this is not any more a problem in the ads-mina2 branch ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: stability of AD trunk
Posted by Norval Hope <nr...@gmail.com>.
I've also been trying to test that the filter evaluates correctly by
creating a few nisNetgroups and ensuring the right search results are
returned, as the NPEs I saw with the old version were in the filter
evaluation code. This required activating the nis.schema which I
attempted to achieve by commenting out nis in
apacheds\bootstrap-partition\pom.xml as follows:
<plugin>
<groupId>org.apache.directory.server</groupId>
<artifactId>apacheds-bootstrap-plugin</artifactId>
<configuration>
<disabledSchemas>
<!--<disabledSchema>nis</disabledSchema>--> !!!!!!!!!!
<disabledSchema>krb5kdc</disabledSchema>
<disabledSchema>samba</disabledSchema>
<disabledSchema>autofs</disabledSchema>
<disabledSchema>apachedns</disabledSchema>
<disabledSchema>corba</disabledSchema>
<disabledSchema>dhcp</disabledSchema>
<disabledSchema>mozilla</disabledSchema>
</disabledSchemas>
however after doing that "mvn install" fails as follows:
[INFO] ------------------------------------------------------------------------
[INFO] Building ApacheDS Core Integration
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] [remote-resources:process {execution: default}]
[WARNING] Attempting to build MavenProject instance for Artifact (org.apache.com
mons:commons-io:1.3.2) of type: jar; constructing POM artifact instead.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 19 source files to C:\src\ad-1.5-vanilla\apacheds\core-integ\ta
rget\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 75 source files to C:\src\ad-1.5-vanilla\apacheds\core-integ\ta
rget\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory: C:\src\ad-1.5-vanilla\apacheds\core-integ\targ
et\surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.directory.server.core.suites.StockCoreISuite
Tests run: 150, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 41.016 sec
Running org.apache.directory.server.core.suites.AuthzISuite
Tests run: 48, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.297 sec
Running org.apache.directory.server.core.operations.search.SearchWithIndicesITest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.203 sec
Running org.apache.directory.server.core.suites.SchemaISuite
javax.naming.NamingException [Root exception is java.lang.NullPointerException]
at org.apache.directory.server.core.jndi.JndiUtils.wrap(JndiUtils.java:40)
at org.apache.directory.server.core.jndi.ServerDirContext.modifyAttributes(ServerDirContext.java:260)
at org.apache.directory.server.core.jndi.ServerDirContext.modifyAttributes(ServerDirContext.java:242)
at org.apache.directory.server.core.schema.SchemaPersistenceIT.enableSchema(SchemaPersistenceIT.java:149)
at org.apache.directory.server.core.schema.SchemaPersistenceIT.testAddAttributeTypePersistence(SchemaPersistenceIT.java:81)
were there any other steps I need to follow in order to get the nis
schema to appear in the trunk AD? If not then the NPEs I saw may have
equivalents in the new code unfortunately (they were triggered in my
case because nisNetGroupTriple didn't have a matching rule defined and
therefore no Normalizer could be found for its values).
Thanks
On Fri, Nov 28, 2008 at 2:36 PM, Norval Hope <nr...@gmail.com> wrote:
> Hi,
>
> On Fri, Nov 28, 2008 at 1:42 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>>
>> I have added a test with a PDU for this filter, and it decodes correctly. I
>> have also added a test in the filter parser to see if it parse correctly
>> this filter, and it does. I would like to see the sent PDU, I suspect there
>> might be a JNDI problem at this point.
>>
>
> Now that I can run the trunk code, I have been able to verify that
> neither the codec parsing problem nor the NPEs occur for it. Sorry for
> the distraction - like you I thought the codec hadn't changed much for
> a long time and therefore felt fairly sure that the problem would
> still be around on the trunk. The problem I saw related to the 0x30
> SEQUENCE around the the substring assertion components, which was on
> the top of the stack when SearchRequest.unstackFilters() was called
> but this method
>
> Here is the output from my test
> (filter="(&(objectClass=nisNetgroup)(|(nisNetGroupTriple=a*a)(nisNetGroupTriple=\28*,acc1,*\29)))")
> which includes the PDU:
> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
> (org.apache.directory.shared.ldap.codec.TwixDecoder:114) DEBUG -
> Decoding the PDU :
> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
> (org.apache.directory.shared.ldap.codec.TwixDecoder:128) DEBUG - 0x30
> 0x81 0xAE 0x02 0x01 0x06 0x63 0x81 0x8B 0x04 0x09 0x6F 0x75 0x3D 0x73
> 0x79 0x73 0x74 0x65 0x6D 0x0A 0x01 0x02 0x0A 0x01 0x00 0x02 0x01 0x00
> 0x02 0x01 0x00 0x01 0x01 0x00 0xA0 0x60 0xA3 0x1A 0x04 0x0B 0x6F 0x62
> 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x04 0x0B 0x6E 0x69 0x73
> 0x4E 0x65 0x74 0x67 0x72 0x6F 0x75 0x70 0xA1 0x42 0xA4 0x1B 0x04 0x11
> 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72 0x69
> 0x70 0x6C 0x65 0x30 0x06 0x80 0x01 0x61 0x82 0x01 0x61 0xA4 0x23 0x04
> 0x11 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72
> 0x69 0x70 0x6C 0x65 0x30 0x0E 0x80 0x01 0x28 0x81 0x06 0x2C 0x61 0x63
> 0x63 0x31 0x2C 0x82 0x01 0x29 0x30 0x0D 0x04 0x0B 0x6F 0x62 0x6A 0x65
> 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0xA0 0x1B 0x30 0x19 0x04 0x17 0x32
> 0x2E 0x31 0x36 0x2E 0x38 0x34 0x30 0x2E 0x31 0x2E 0x31 0x31 0x33 0x37
> 0x33 0x30 0x2E 0x33 0x2E 0x34 0x2E 0x32
> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
> (org.apache.directory.shared.ldap.codec.TwixDecoder:135) DEBUG -
> Decoded LdapMessage : LdapMessage
> message Id : 6
> Search Request
> Base Object : 'ou=system'
> Scope : whole subtree
> Deref Aliases : never Deref Aliases
> Size Limit : no limit
> Time Limit : no limit
> Types Only : false
> Filter : '(&(objectClass=nisNetgroup)(|(a*a)((*,acc1,*))))'
> Attributes : objectclass
> Control
> Control type : '2.16.840.1.113730.3.4.2'
> Criticality : 'false'
>
> Note that the extra ()s around "((*,acc1,*))" aren't actually a
> problem but rather due to the toString() not requoting the \28 and \29
> (which was one of the fixes in my patch for DIRSERVER-1247).
>
> Thanks Emmanuel and Pierre-Arnaud!
>
Re: stability of AD trunk
Posted by Norval Hope <nr...@gmail.com>.
Hi,
On Fri, Nov 28, 2008 at 1:42 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> I have added a test with a PDU for this filter, and it decodes correctly. I
> have also added a test in the filter parser to see if it parse correctly
> this filter, and it does. I would like to see the sent PDU, I suspect there
> might be a JNDI problem at this point.
>
Now that I can run the trunk code, I have been able to verify that
neither the codec parsing problem nor the NPEs occur for it. Sorry for
the distraction - like you I thought the codec hadn't changed much for
a long time and therefore felt fairly sure that the problem would
still be around on the trunk. The problem I saw related to the 0x30
SEQUENCE around the the substring assertion components, which was on
the top of the stack when SearchRequest.unstackFilters() was called
but this method
Here is the output from my test
(filter="(&(objectClass=nisNetgroup)(|(nisNetGroupTriple=a*a)(nisNetGroupTriple=\28*,acc1,*\29)))")
which includes the PDU:
2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
(org.apache.directory.shared.ldap.codec.TwixDecoder:114) DEBUG -
Decoding the PDU :
2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
(org.apache.directory.shared.ldap.codec.TwixDecoder:128) DEBUG - 0x30
0x81 0xAE 0x02 0x01 0x06 0x63 0x81 0x8B 0x04 0x09 0x6F 0x75 0x3D 0x73
0x79 0x73 0x74 0x65 0x6D 0x0A 0x01 0x02 0x0A 0x01 0x00 0x02 0x01 0x00
0x02 0x01 0x00 0x01 0x01 0x00 0xA0 0x60 0xA3 0x1A 0x04 0x0B 0x6F 0x62
0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x04 0x0B 0x6E 0x69 0x73
0x4E 0x65 0x74 0x67 0x72 0x6F 0x75 0x70 0xA1 0x42 0xA4 0x1B 0x04 0x11
0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72 0x69
0x70 0x6C 0x65 0x30 0x06 0x80 0x01 0x61 0x82 0x01 0x61 0xA4 0x23 0x04
0x11 0x6E 0x69 0x73 0x4E 0x65 0x74 0x47 0x72 0x6F 0x75 0x70 0x54 0x72
0x69 0x70 0x6C 0x65 0x30 0x0E 0x80 0x01 0x28 0x81 0x06 0x2C 0x61 0x63
0x63 0x31 0x2C 0x82 0x01 0x29 0x30 0x0D 0x04 0x0B 0x6F 0x62 0x6A 0x65
0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0xA0 0x1B 0x30 0x19 0x04 0x17 0x32
0x2E 0x31 0x36 0x2E 0x38 0x34 0x30 0x2E 0x31 0x2E 0x31 0x31 0x33 0x37
0x33 0x30 0x2E 0x33 0x2E 0x34 0x2E 0x32
2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
(org.apache.directory.shared.ldap.codec.TwixDecoder:135) DEBUG -
Decoded LdapMessage : LdapMessage
message Id : 6
Search Request
Base Object : 'ou=system'
Scope : whole subtree
Deref Aliases : never Deref Aliases
Size Limit : no limit
Time Limit : no limit
Types Only : false
Filter : '(&(objectClass=nisNetgroup)(|(a*a)((*,acc1,*))))'
Attributes : objectclass
Control
Control type : '2.16.840.1.113730.3.4.2'
Criticality : 'false'
Note that the extra ()s around "((*,acc1,*))" aren't actually a
problem but rather due to the toString() not requoting the \28 and \29
(which was one of the fixes in my patch for DIRSERVER-1247).
Thanks Emmanuel and Pierre-Arnaud!
Re: stability of AD trunk
Posted by Emmanuel Lecharny <el...@gmail.com>.
Norval Hope wrote:
> Hi Emmanuel,
>
> <snip/>
> 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))"
>
I have added a test with a PDU for this filter, and it decodes
correctly. I have also added a test in the filter parser to see if it
parse correctly this filter, and it does. I would like to see the sent
PDU, I suspect there might be a JNDI problem at this point.
Here is the PDU I have created :
/**
* Test the decoding of a SearchRequest with a complex filter :
* (&(objectClass=person)(|(cn=Tori*)(sn=Jagger)))
*/
@Test
public void testDecodeSearchRequestComplexFilter()
{
Asn1Decoder ldapDecoder = new LdapDecoder();
ByteBuffer stream = ByteBuffer.allocate( 0x77 );
stream.put( new byte[]
{
0x30, 0x75, // LdapMessage
0x02, 0x01, 0x06, // message Id = 6
0x63, 0x53, // SearchRequest
0x04, 0x09, // BasDN 'ou=system'
0x6F, 0x75, 0x3D, 0x73, 0x79, 0x73, 0x74, 0x65, 0x6D,
0x0A, 0x01, 0x02, // scope = SUBTREE
0x0A, 0x01, 0x03, // derefAlias = 3
0x02, 0x01, 0x00, // sizeLimit = none
0x02, 0x01, 0x00, // timeLimit = none
0x01, 0x01, 0x00, // types only = false
(byte)0xA0, 0x35, // AND
(byte)0xA3, 0x15, // equals
0x04, 0x0B, // 'objectclass'
0x6F, 0x62, 0x6A, 0x65, 0x63, 0x74, 0x43, 0x6C,
0x61, 0x73, 0x73,
0x04, 0x06, // 'person'
0x70, 0x65, 0x72, 0x73, 0x6F, 0x6E,
(byte)0xA1, 0x1C, // OR
(byte)0xA4, 0x0C, // substrings : 'cn=Tori*'
0x04, 0x02, // 'cn'
0x63, 0x6E,
0x30, 0x06, // initial = 'Tori'
(byte)0x80, 0x04,
0x54, 0x6F, 0x72, 0x69,
(byte)0xA3, 0x0C, // equals
0x04, 0x02, // 'sn'
0x73, 0x6E,
0x04, 0x06, // 'Jagger'
0x4A, 0x61, 0x67, 0x67, 0x65, 0x72,
0x30, 0x00, // Control
(byte)0xA0, 0x1B,
0x30, 0x19,
0x04, 0x17,
'2', '.', '1', '6', '.', '8', '4', '0', '.',
'1', '.', '1', '1', '3', '7', '3', '0', '.',
'3', '.', '4', '.', '2'
} );
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org