Save This Page
Home » commons-digester-1.8-src » org.apache.commons » digester » [javadoc | source]
org.apache.commons.digester
public class: OverlappingCallMethodRuleTestCase [javadoc | source]
java.lang.Object
   junit.framework.TestCase
      org.apache.commons.digester.OverlappingCallMethodRuleTestCase

Tests for situations where CallMethodRule instances and their parameters overlap each other.

Field Summary
 String itemId     
 String itemName     
Constructor:
 public OverlappingCallMethodRuleTestCase(String name) 
    Construct a new instance of this test case.
    Parameters:
    name - Name of the test case
Method from org.apache.commons.digester.OverlappingCallMethodRuleTestCase Summary:
setItemId,   setItemName,   setUp,   suite,   tearDown,   testItem1,   testItem2,   testItem3,   testItem4,   testWildcard1,   testWildcard2
Methods from java.lang.Object:
equals,   getClass,   hashCode,   notify,   notifyAll,   toString,   wait,   wait,   wait
Method from org.apache.commons.digester.OverlappingCallMethodRuleTestCase Detail:
 public  void setItemId(String id) 
 public  void setItemName(String name) 
 public  void setUp() 
    Set up instance variables required by this test case.
 public static Test suite() 
    Return the tests included in this test suite.
 public  void tearDown() 
    Tear down instance variables required by this test case.
 public  void testItem1() throws IOException, SAXException 
 public  void testItem2() throws IOException, SAXException 
 public  void testItem3() throws IOException, SAXException 
 public  void testItem4() throws IOException, SAXException 
    This is an "anti-test" that demonstrates how digester can fails to produce the correct results, due to a design flaw (or at least limitation) in the way that CallMethodRule and CallParamRule work.

    The following sequence always fails:

    • CallMethodRule A fires (pushing params array)
    • CallMethodRule B fires (pushing params array)
    • params rule for A fires --> writes to params of method B!
    • params rule for B fires --> overwrites params for method B
    The result is that method "b" appears to work ok, but method "a" loses its input parameters.

    One solution is for CallParamRule objects to know which CallMethodRule they are associated with. Even this might fail in corner cases where the same rule is associated with multiple patterns, or with wildcard patterns which cause a rule to fire in a "recursive" manner. However implementing this is not possible with the current digester design.

 public  void testWildcard1() throws IOException, SAXException 
    This test checks that CallParamRule instances which fetch data from xml attributes work ok when invoked "recursively", ie a rule instances' methods gets called in the order begin[1]/begin[2]/body[2]/end[2]/body[1]/end[1]
 public  void testWildcard2() throws IOException, SAXException 
    This test checks that CallParamRule instances which fetch data from the xml element body work ok when invoked "recursively", ie a rule instances' methods gets called in the order begin[1]/begin[2]/body[2]/end[2]/body[1]/end[1]