Uploaded image for project: 'Commons Digester'
  1. Commons Digester
  2. DIGESTER-143

Unintuitive, possibly broken behaviour.



    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Not A Problem
    • Affects Version/s: 2.1
    • Fix Version/s: 3.0
    • Labels:
    • Environment:

      Linux 64 bits


      When one tag is a substring of another tag and both are used as xml patterns, such as:
      "rdf:RDF/pgterms:etext/dc:creator/rdf:Bag/rdf:li" (instances in a collection of creators)

      the callback to the first is called once with empty strings ("") as the body of the tag if it encounters a instance of the second tag.

      If additionally the first tag has a argument
      "rdf:RDF/pgterms:etext/dc:creator rdf:type="Literal"" and you bind things correctly for a two arguments callback with the text body and the argument value ("Literal"), the callback of the first will be called with a null rdf:type argument and a empty string as the body. You can use this to distinguish the bogus callback as a workaround, but requires a additional bean method and confusing binding too.

      The best thing would be if these empty strings callback were avoidable. I can just test for empty string in the callback, however, i'm trying also to create assertions on the xml content (including, no empty strings).

      If the bogus callback must exist, one of the ways to make it obvious and distinguishable, would be to use null as the default value, instead of "". No xml document will have the computation null value, unless some very strange java binding is happening, in which case, you're asking for trouble. "" is even worse, because it is common to both domains.

      So RFE:
      1) Avoid the bogus callback of the smaller xml tree branch if you can.
      2) if you can't, use null as a default value instead of the indistinguishable "".
      3) if 2) document this behavior in the javadoc and the digester FAQ.


        1. Main.java
          2 kB



            • Assignee:
              simone.tripodi Simone Tripodi
              i30817 i30817
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: