Commons Digester
  1. Commons Digester
  2. DIGESTER-39

[digester] Exact patterns overwrite patterns with wildcards

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      In the code below the Rules with the wildcard-patterns don't seem to be fired
      (at least, when using the xml even more below). If the exact matching rules are
      put in comment, the wildcard matching rules do get fired.
      It seems like the SetRoot rule overwrites the ObjectCreate rule.
      Furthermore the pattern "datadescriptor//property" doesn't seem to match
      anywhere, but this may be due to a misunderstanding of the (rather short)
      explanation in the docs.

      yours sincerely,
      Maarten Van Puymbroeck.

      – Java Code –

      // Properties
      // create the object
      digester.addObjectCreate("*/property", RealProperty.class);
      // initialize properties
      String[] properties = new String[]

      {"name", "key", "tooltip", "mapsWith", "type", "ref"}

      ;
      digester.addSetProperties("*/property", properties, properties);
      // add the properties to the correct collection
      digester.addSetRoot("datadescriptor/properties/property", "addProperty");//,
      "be.generic.Property");
      digester.addSetRoot("datadescriptor/searchproperties/property",
      "addSearchProperty");//, "be.generic.Property");
      digester.addSetRoot("datadescriptor/listproperties/property",
      "addListProperty");//, "be.generic.Property");
      digester.addSetRoot("datadescriptor/editproperties/property",
      "addEditProperty");//, "be.generic.Property");

      – XML –

      <?xml version="1.0" encoding="UTF-8"?>
      <!--Sample XML file generated by XMLSPY v5 rel. 4 U (http://www.xmlspy.com)-->
      <datadescriptor class="be.dto.LongReturnDTO"
      dataTypeName="GenericExample">
      <actions create="true" update="true" delete="true"/>
      <properties>
      <property name="start_date" key="i-startDate" tooltip="i-startDateTooltip"
      mapsWith="startDate" type="Date" />
      </properties>
      <searchproperties>
      <property name="expiration_date" key="i-expirationDate"
      tooltip="i-expirationDateSearchTooltip" mapsWith="endDate" type="Date" />
      </searchproperties>
      <listproperties>
      <property name="expiration_date" key="i-expirationDate"
      tooltip="i-expirationDateListTooltip" mapsWith="endDate" type="Date" />
      <property ref="start_date" tooltip="i-startDateListTooltip"/>
      </listproperties>
      <editproperties>
      <allProperties />
      </editproperties>
      </datadescriptor>

        Activity

        Hide
        Simon Kitching added a comment -

        I've updated the javadoc for package o.a.c.digester, and the javadoc for the
        RulesBase class to (hopefully) be clearer. Thanks for raising the issue.

        Regards,

        Simon

        Show
        Simon Kitching added a comment - I've updated the javadoc for package o.a.c.digester, and the javadoc for the RulesBase class to (hopefully) be clearer. Thanks for raising the issue. Regards, Simon
        Hide
        Simon Kitching added a comment -

        This behaviour is deliberate, and not a bug. Wildcard patterns are ignored if an
        explicit match can be found (and when multiple wildcard patterns match, only the
        longest, ie most explicit, pattern is considered a match).

        The intent is that rules can be added for "an <a> tag anywhere", but then for
        that behaviour to be explicitly overridden for specific cases, eg "but not an
        <a> that is a direct child of an <x>".

        If you have rules A and B registered for pattern "*/a", then want to add an
        additional rule C for pattern "x/a" only, then what you need to do is add
        three rules for "x/a": A,B and C.

        Note that by using
        Rule ruleA = new ObjectCreateRule();
        Rule ruleB = new SetNextRule();
        Rule ruleC = new SetPropertiesRule();

        digester.addRule("*/a", ruleA);
        digester.addRule("*/a", ruleB);
        digester.addRule("x/a", ruleA);
        digester.addRule("x/a", ruleB);
        digester.addRule("x/a", ruleC);

        you have associated the same rule instances A and B with multiple patterns, thus
        avoiding creating extra rule object instances.

        I agree this behaviour (explicit rules override wildcard rules in the default
        RulesBase rule-matching class) is not properly documented, and will leave this
        bug open as a reminder to add proper javadocs on this subject.

        Sorry if this caused any confusion...

        NB1: I don't see why your datadecriptor/.../property patterns didn't match. They
        should as far as I can see.

        NB2: In general, I think SetRootRule should be avoided as it generally implies
        that the xml's explicit nesting is not being properly respected. I suggest using
        alternative rules if possible.

        Show
        Simon Kitching added a comment - This behaviour is deliberate, and not a bug. Wildcard patterns are ignored if an explicit match can be found (and when multiple wildcard patterns match, only the longest, ie most explicit, pattern is considered a match). The intent is that rules can be added for "an <a> tag anywhere", but then for that behaviour to be explicitly overridden for specific cases, eg "but not an <a> that is a direct child of an <x>". If you have rules A and B registered for pattern "*/a", then want to add an additional rule C for pattern "x/a" only, then what you need to do is add three rules for "x/a": A,B and C. Note that by using Rule ruleA = new ObjectCreateRule(); Rule ruleB = new SetNextRule(); Rule ruleC = new SetPropertiesRule(); digester.addRule("*/a", ruleA); digester.addRule("*/a", ruleB); digester.addRule("x/a", ruleA); digester.addRule("x/a", ruleB); digester.addRule("x/a", ruleC); you have associated the same rule instances A and B with multiple patterns, thus avoiding creating extra rule object instances. I agree this behaviour (explicit rules override wildcard rules in the default RulesBase rule-matching class) is not properly documented, and will leave this bug open as a reminder to add proper javadocs on this subject. Sorry if this caused any confusion... NB1: I don't see why your datadecriptor/.../property patterns didn't match. They should as far as I can see. NB2: In general, I think SetRootRule should be avoided as it generally implies that the xml's explicit nesting is not being properly respected. I suggest using alternative rules if possible.

          People

          • Assignee:
            Unassigned
            Reporter:
            Maarten Van Puymbroeck
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development