You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by ji...@apache.org on 2004/04/18 23:07:53 UTC
[jira] Created: (DIRSNICKERS-42) Write a ResultRule
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIRSNICKERS-42
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIRSNICKERS-42
Summary: Write a ResultRule
Type: Task
Status: Open
Priority: Major
Project: Directory Snickers
Components:
LDAP Provider
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 18 Apr 2004 2:07 PM
Updated: Sun, 18 Apr 2004 2:07 PM
Description:
We need to write a rule that will create an LdapResult object and populate it using any one of the response PDU's that have the LDAPResult or its components.
I believe the LDAP message API sheilds users from protocol oddities where some responses do not have an embedded LDAPResult but its components. If this is the case the API normalizes conditions so a nested LdapResult object is found in either case. This makes the API easier and more consistant for the user.
This rule should work with any response that has the LDAPResult or its components embedded in it so we cannot presume static patterns. The key here is to just push ASN.1 primitive onto the appropriate stack then have the finish() method of the LDAPResult pop the appropriate stacks and populate the LdapResult it's building.
The rule will presume the following. The intStack has the resultCode pushed onto it. The objectStack has the matchedDN, the errorMessage, and the Referral objects pushed onto it in that order. Both the OCTET STRINGS are not OPTIONAL so even if they are of zero length an empty ByteBuffer should be found on the stack in the place of each field. Since the Referal element in the LDAPResult sequence is optional we will need to peek at the stack to make sure the object is a referral. If so then it is popped and set on the LdapResult.
We need a ReferralRule too to build the referral but that's another issue.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (DIRSNICKERS-42) Write a ResultRule
Posted by ji...@apache.org.
Message:
The following issue has been closed.
Resolver: Alex Karasulu
Date: Fri, 28 May 2004 10:19 PM
We actually created multiple rules instead to acheive the same effect. See the test cases for BindResponseRule or DeleteResponseRule.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIRSNICKERS-42
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIRSNICKERS-42
Summary: Write a ResultRule
Type: Task
Status: Closed
Priority: Major
Resolution: WON'T FIX
Project: Directory Snickers
Components:
LDAP Provider
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 18 Apr 2004 2:07 PM
Updated: Fri, 28 May 2004 10:19 PM
Description:
We need to write a rule that will create an LdapResult object and populate it using any one of the response PDU's that have the LDAPResult or its components.
I believe the LDAP message API sheilds users from protocol oddities where some responses do not have an embedded LDAPResult but its components. If this is the case the API normalizes conditions so a nested LdapResult object is found in either case. This makes the API easier and more consistant for the user.
This rule should work with any response that has the LDAPResult or its components embedded in it so we cannot presume static patterns. The key here is to just push ASN.1 primitive onto the appropriate stack then have the finish() method of the LDAPResult pop the appropriate stacks and populate the LdapResult it's building.
The rule will presume the following. The intStack has the resultCode pushed onto it. The objectStack has the matchedDN, the errorMessage, and the Referral objects pushed onto it in that order. Both the OCTET STRINGS are not OPTIONAL so even if they are of zero length an empty ByteBuffer should be found on the stack in the place of each field. Since the Referal element in the LDAPResult sequence is optional we will need to peek at the stack to make sure the object is a referral. If so then it is popped and set on the LdapResult.
We need a ReferralRule too to build the referral but that's another issue.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira