You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Jesse McConnell (JIRA)" <ji...@apache.org> on 2007/09/06 23:51:28 UTC
[jira] Created: (DIRSERVER-1058) context.search errors on embedded
apacheds 1.5.1
context.search errors on embedded apacheds 1.5.1
--------------------------------------------------
Key: DIRSERVER-1058
URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
Project: Directory ApacheDS
Issue Type: Bug
Components: ldap
Affects Versions: 1.5.1
Reporter: Jesse McConnell
I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
just running 'mvn test' will show the error.
Two things are in play here
1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
Attributes
Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
Attribute id : 'cn', Values : ['trygvis']
Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
Attribute id : 'javaClassNames', Values : []
Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-1058) context.search errors on
embedded apacheds 1.5.1
Posted by "Jesse McConnell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525770 ]
Jesse McConnell commented on DIRSERVER-1058:
--------------------------------------------
Following your work around I changed these parts of the test case..
When making a test user I switched to creating the subcontext:
context.createSubcontext( dn, attributes );
//context.bind( dn, attributes );
Then when asserting that the record exists correctly I don't lookup anymore I search like this:
SearchControls ctls = new SearchControls();
ctls.setDerefLinkFlag( true );
ctls.setSearchScope( SearchControls.ONELEVEL_SCOPE );
ctls.setReturningAttributes( new String[] { "*" } );
BasicAttributes matchingAttributes = new BasicAttributes();
matchingAttributes.put( attribute, value );
NamingEnumeration<SearchResult> results = context.search( suffix, matchingAttributes );
and then assert that the record returned and contained the goods...
so this work around works for my needs :)
> context.search errors on embedded apacheds 1.5.1
> --------------------------------------------------
>
> Key: DIRSERVER-1058
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.1
> Reporter: Jesse McConnell
> Assignee: Emmanuel Lecharny
>
> I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
> just running 'mvn test' will show the error.
> Two things are in play here
> 1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
> 2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
> Attributes
> Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
> Attribute id : 'cn', Values : ['trygvis']
> Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
> Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
> Attribute id : 'javaClassNames', Values : []
> Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
> Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRSERVER-1058) context.search errors on embedded
apacheds 1.5.1
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny reassigned DIRSERVER-1058:
--------------------------------------------
Assignee: Emmanuel Lecharny
> context.search errors on embedded apacheds 1.5.1
> --------------------------------------------------
>
> Key: DIRSERVER-1058
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.1
> Reporter: Jesse McConnell
> Assignee: Emmanuel Lecharny
>
> I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
> just running 'mvn test' will show the error.
> Two things are in play here
> 1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
> 2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
> Attributes
> Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
> Attribute id : 'cn', Values : ['trygvis']
> Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
> Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
> Attribute id : 'javaClassNames', Values : []
> Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
> Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRSERVER-1058) context.search errors on embedded
apacheds 1.5.1
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny updated DIRSERVER-1058:
-----------------------------------------
Fix Version/s: 1.5.2
> context.search errors on embedded apacheds 1.5.1
> --------------------------------------------------
>
> Key: DIRSERVER-1058
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.1
> Reporter: Jesse McConnell
> Assignee: Emmanuel Lecharny
> Fix For: 1.5.2
>
>
> I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
> just running 'mvn test' will show the error.
> Two things are in play here
> 1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
> 2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
> Attributes
> Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
> Attribute id : 'cn', Values : ['trygvis']
> Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
> Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
> Attribute id : 'javaClassNames', Values : []
> Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
> Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRSERVER-1058) context.search errors on embedded
apacheds 1.5.1
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny resolved DIRSERVER-1058.
------------------------------------------
Resolution: Won't Fix
Ok, marked reolved because this is not a clear bug, I think...
Jesse, you can reopen the issue if needed.
> context.search errors on embedded apacheds 1.5.1
> --------------------------------------------------
>
> Key: DIRSERVER-1058
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.1
> Reporter: Jesse McConnell
> Assignee: Emmanuel Lecharny
> Fix For: 1.5.2
>
>
> I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
> just running 'mvn test' will show the error.
> Two things are in play here
> 1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
> 2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
> Attributes
> Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
> Attribute id : 'cn', Values : ['trygvis']
> Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
> Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
> Attribute id : 'javaClassNames', Values : []
> Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
> Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRSERVER-1058) context.search errors on
embedded apacheds 1.5.1
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525641 ]
Emmanuel Lecharny commented on DIRSERVER-1058:
----------------------------------------------
I have debugged the test. There a lot of problems...
1) The 'bind' semantic is totally different in JNDI and in LDAP. When someone issue a JNDI bind operation, a new entry is added to the current context. The LDAP bind operation just create a link to a specific part of the server, and proceed an authentification. As a result, in your case, the object which is a BasicAttributes is serialized to a Java class and stored as is in the server. So when you get it back, you get the deserialized form of this object. You could berfectly have 'bound' any kind of object, assuming it implement Serializable.
2) Fetching an object using lookup() returns the stored object. If you consider what happens when you called the bind(), an entry has been created which contains a javaSerializedObject attribute which contains the object you are 'binding'. So your entry is encapsulated into another entry, created by the JNDI layer itself.
Now, there are two things :
1) there is something wrong in the way we handle the JNDI bind() operation on the server. There is no reason why the server behavior should change depending on the way you use it : remotly or embedded
2) You can avoid all those problems by avoid using bind/lookup operations. Just create a DirContext() object, then create a subContext(), and search() for the object.
> context.search errors on embedded apacheds 1.5.1
> --------------------------------------------------
>
> Key: DIRSERVER-1058
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.1
> Reporter: Jesse McConnell
> Assignee: Emmanuel Lecharny
>
> I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
> just running 'mvn test' will show the error.
> Two things are in play here
> 1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
> 2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
> Attributes
> Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
> Attribute id : 'cn', Values : ['trygvis']
> Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
> Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
> Attribute id : 'javaClassNames', Values : []
> Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
> Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRSERVER-1058) context.search errors on embedded
apacheds 1.5.1
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Lecharny closed DIRSERVER-1058.
----------------------------------------
> context.search errors on embedded apacheds 1.5.1
> --------------------------------------------------
>
> Key: DIRSERVER-1058
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1058
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: 1.5.1
> Reporter: Jesse McConnell
> Assignee: Emmanuel Lecharny
> Fix For: 1.5.2
>
>
> I have talked to elecharny on this on irc but I have it isolated into a single artifact and have it manifesting on 1.5.1 now.
> https://svn.codehaus.org/plexus/plexus-sandbox/trunk/plexus-apacheds
> just running 'mvn test' will show the error.
> Two things are in play here
> 1) the search filter should be (&(objectClass=inetOrgPerson)(cn=trygvis)) but this doesn't return anything...changing it to just the (cn=trygvis) will return a record though.
> 2) that record looks to have the following attributes which would explain why the objectClass=inetOrgPerson check would fail, its not in here.
> Attributes
> Attribute id : 'objectClass', Values : ['javaObject', 'javaContainer', 'javaSerializedObject', 'top']
> Attribute id : 'cn', Values : ['trygvis']
> Attribute id : 'javaSerializedData', Values : [0xAC 0xED 0x00 0x05 0x73 0x72 0x00 0x26 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x73 0x45 0x1D 0x18 0xD6 0xA9 0x55 0x39 0xD8 0x03 0x00 0x01 0x5A 0x00 0x0A 0x69 0x67 0x6E 0x6F 0x72 0x65 0x43 0x61 0x73 0x65 0x78 0x70 0x00 0x77 0x04 0x00 0x00 0x00 0x03 0x73 0x72 0x00 0x25 0x6A 0x61 0x76 0x61 0x78 0x2E 0x6E 0x61 0x6D 0x69 0x6E 0x67 0x2E 0x64 0x69 0x72 0x65 0x63 0x74 0x6F 0x72 0x79 0x2E 0x42 0x61 0x73 0x69 0x63 0x41 0x74 0x74 0x72 0x69 0x62 0x75 0x74 0x65 0x5D 0x95 0xD3 0x2A 0x66 0x85 0x65 0xBE 0x03 0x00 0x02 0x5A 0x00 0x07 0x6F 0x72 0x64 0x65 0x72 0x65 0x64 0x4C 0x00 0x06 0x61 0x74 0x74 0x72 0x49 0x44 0x74 0x00 0x12 0x4C 0x6A 0x61 0x76 0x61 0x2F 0x6C 0x61 0x6E 0x67 0x2F 0x53 0x74 0x72 0x69 0x6E 0x67 0x3B 0x78 0x70 0x00 0x74 0x00 0x0B 0x6F 0x62 0x6A 0x65 0x63 0x74 0x43 0x6C 0x61 0x73 0x73 0x77 0x04 0x00 0x00 0x00 0x02 0x74 0x00 0x03 0x74 0x6F 0x70 0x74 0x00 0x0D 0x69 0x6E 0x65 0x74 0x4F 0x72 0x67 0x50 0x65 0x72 0x73 0x6F 0x6E 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x08 0x74 0x65 0x73 0x74 0x41 0x74 0x74 0x72 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x04 0x74 0x65 0x73 0x74 0x78 0x73 0x71 0x00 0x7E 0x00 0x02 0x00 0x74 0x00 0x02 0x63 0x6E 0x77 0x04 0x00 0x00 0x00 0x01 0x74 0x00 0x07 0x74 0x72 0x79 0x67 0x76 0x69 0x73 0x78 0x78 ]
> Attribute id : 'javaClassName', Values : ['javax.naming.directory.BasicAttributes']
> Attribute id : 'javaClassNames', Values : []
> Now, if you look at the test case, doing a straight forward Object o = context.lookup( dn ); will return an Attributes object that is coherent and contains the objects I am interested in getting, but the Attributes in the SearchResult are messed up or something.
> Another interesting thing is that the context.search will work successfully with this code if I connect to apacheds running standalone, it seems to manifest this way when its embedded like this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.