Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Message-ID: <933832196.1102458794871.JavaMail.apache@nagoya>
Date: Tue, 7 Dec 2004 14:33:14 -0800 (PST)
From: "Alex Karasulu (JIRA)" <directory-dev@incubator.apache.org>
To: directory-dev@incubator.apache.org
Subject: [jira] Closed: (DIRSNICKERS-46) Rules fire in (pseudo) parallel mode
In-Reply-To: <831547917.1085807700919.JavaMail.apache@nagoya>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

     [ http://nagoya.apache.org/jira/browse/DIRSNICKERS-46?page=history ]
     
Alex Karasulu closed DIRSNICKERS-46:
------------------------------------

    Resolution: Fixed

also fixed ages ago

> Rules fire in (pseudo) parallel mode
> ------------------------------------
>
>          Key: DIRSNICKERS-46
>          URL: http://nagoya.apache.org/jira/browse/DIRSNICKERS-46
>      Project: Directory Snickers
>         Type: Bug
>   Components: BER Runtime
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu
>     Priority: Minor

>
> Rules added to the digester's rule base using the same pattern are fired together at the same: all rules for the same pattern have tag() called on a match first together, then length(), then value() and finally finish().  So if r1, r2, and r3 are added to the rule base using the same pattern then the sequence of rule method invokations for a match would be:
> r1.tag()
> r2.tag()
> r3.tag()
> r1.length()
> r2.length()
> r3.length()
> ============================================
> -- seq of calls might more than one times --
> r1.value()
> r2.value()
> r3.value()
> ============================================
> r1.finish()
> r2.finish()
> r3.finish()
> This may cause unusual behavoir since we presumed the sequential operation of rules on the same pattern.  So we supposed the invokations would look like so:
> r1.tag()
> r1.length()
> [r1.value()]* - might occur one or more times
> r1.finish()
> r2.tag()
> r2.length()
> [r2.value()]* - might occur one or more times
> r2.finish()
> r3.tag()
> r3.length()
> [r3.value()]* - might occur one or more times
> r3.finish()
> We discovered this problem when the LDAP Result errorMessage rule and the matchedDN rules were overwriting one another.  These two fields have the same nesting patterns and come right after one another with the matchedDN field first.  What was happening was both were firing for each field that arrived.  So when the matchedDN appeared both fired and the errorMessage of the LDAP result was set to the 
> matchedDN value and the matchedDN of the LDAP result was set correctly however when the errorMessage arrived and triggered the two rules to fire again this time the matchedDN of the LDAP result was set to the errorMessage and the errorMessage field was now set correctly.  This is not an idea situation.  There may need to be some way to alternate rules within a TagNode so that alternate across pattern matches.  This way two different matches in time with the same pattern can be matched by two different rules.
> We need to think about this for some time.  Changes may not be needed if there seems to be no use case requirements, however I doubt that.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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