Inconsistent rule map usage in XMLParser initRules method

[kenj1]

Hello. In reviewing the XMLParser class code, I noticed that the initRules method looks up the rule key as a String but put's it into the same map as an int (hashCode). This may be a missed change when you improved the parse performance rule lookup from String to Hashcode. This issue shows up in all 3 rules maps.

The net result is a location path will always create a new rulelist and thus only ever have one rule associated with it (last rule definition wins for that path). This could lead to wasted memory and/or unexpected behavior.

KenJ

[ghost]

Ken, great catch!

Leaving a quick note for myself, the issue Ken is reporting can be easily seen in initRules with any of the switch-case statements where the rule is attempted lookup by its name, then stored by its hashcode:

// Get the rule list for this path
ruleList = tagRuleMap.get(rule.getLocationPath());

// If there wasn't already a rule list, create and add it
if (ruleList == null) {
    ruleList = new ArrayList<IRule<T>>(3);
    tagRuleMap.put(rule.getLocationPath().hashCode(), ruleList);
}