commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32756] - [digester] Exact patterns overwrite patterns with wildcards
Date Sat, 18 Dec 2004 11:19:52 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32756>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32756


skitching@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




------- Additional Comments From skitching@apache.org  2004-12-18 12:19 -------
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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message