directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Norval Hope" <nrh...@gmail.com>
Subject Re: stability of AD trunk
Date Fri, 28 Nov 2008 03:36:09 GMT
Hi,

On Fri, Nov 28, 2008 at 1:42 AM, Emmanuel Lecharny <elecharny@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!

Mime
View raw message