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 Fri, 28 Nov 2008 11:28:37 GMT
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></groupId>
>         <artifactId>apacheds-bootstrap-plugin</artifactId>
>         <configuration>
>           <disabledSchemas>
>             <!--<disabledSchema>nis</disabledSchema>-->  !!!!!!!!!!
>             <disabledSchema>krb5kdc</disabledSchema>
> however after doing that "mvn install" fails as follows:
> Running
> javax.naming.NamingException [Root exception is java.lang.NullPointerException]
>         at
>         at
>         at
>         at
>         at
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
            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.

> On Fri, Nov 28, 2008 at 2:36 PM, Norval Hope <> wrote:
>> Hi,
>> 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]
>> ( DEBUG  -
>> Decoding the PDU :
>> 2008-11-28 14:25:14,953 68000 [pool-1-thread-6]
>> ( 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]
>> ( 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

View raw message