directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Closed: (DIRSNICKERS-42) Write a ResultRule
Date Sat, 29 May 2004 05:20:01 GMT
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


Mime
View raw message