0

I'm on the incubating Apache JSPWiki team and trying to upgrade our project from JDOM 1.1.2 to JDOM 2.0.5. 98% of the conversion seems to work fine but I've come across one problem preventing us from upgrading, involving JDOM2's XMLOutputter.outputElementContent(). Namely, we always add a processing instruction to disable output escaping but we still expect ampersands and quotes within attributes to be escaped to & and ". JDOM1 handles this PI as we want, but JDOM2 interprets this instruction to also shut off output escaping within attribute values. I'm unsure if this is a bug/feature in JDOM2 or if JSPWiki is improperly relying on a bug/feature in JDOM1. [1] shows how we configure the Format element in JSPWiki prior to calling outputElementContent().

For example, in JDOM1:

<a href="http://www.google.com/?p=a&c=d">Hello</a>

gets rendered as:

<a href="http://www.google.com/?p=a&amp;c=d">Hello</a> (good, ampersand is escaped)

This is because in JDOM1, XMLOutputter.printAttibutes()[2] escapes the attribute values regardless of the processing instruction.

but in JDOM2 we get:

<a href="http://www.google.com/?p=a&c=d">Hello</a>  (bad, still an ampersand character)

... because in JDOM2, AbstractXMLOutputProcessor's attributeEscapedEntitiesFilter[3] will do the escaping only if "getEscapeOutput()" is true, but getEscapeOutput is automatically set to false[4] if the disable-output-escaping PI is set.

If we call Format.setIgnoreTrAXEscapingPIs() (or just not add the disable-output-escaping PI to begin with), we end up having the opposite problem of the tag being escaped.

Can anyone think of a good/simple solution for us?

Thanks, Glen

[1] http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-war/src/main/java/org/apache/wiki/render/XHTMLRenderer.java?revision=1486481&view=markup#l56

[2] http://grepcode.com/file/repo1.maven.org/maven2/org.jdom/jdom/1.1/org/jdom/output/XMLOutputter.java#1132

[3] http://grepcode.com/file/repo1.maven.org/maven2/org.jdom/jdom2/2.0.4/org/jdom2/output/support/AbstractXMLOutputProcessor.java#392

[4] http://grepcode.com/file/repo1.maven.org/maven2/org.jdom/jdom2/2.0.4/org/jdom2/output/support/AbstractXMLOutputProcessor.java#665

Glen Mazza
  • 748
  • 1
  • 6
  • 27
  • 1
    Hey Glen. I'm thinking on this one.... just so you know. My instinct is to say that JDOM 2.x is doing the right thing.... It should be relatively easy to test using a different engine other than JDOM.... but who's to say that other engine is doing it right. My instinct is that attribute valeus should be handled the same as Text content, (which is what JDOM 2.x is doing). This is not something I have test cases for on the JDOM 1.x side, so I do not have a precedent in JDOM 1.x to follow. In general I am very careful to maintain functional compatibility between 1.x and 2.x. Will look in to it. – rolfl Jul 03 '13 at 14:58
  • Well, it seemed that attribute values are being handled not just the same as text content but as elements as well, i.e., it's all-or-nothing (but I may easily have misread the code.) If I have an HTML anchor tag I may want to keep the braces around the anchors (have it unescaped) but at the same time make sure any ampersands in the attribute values and text content are still escaped. Does JDOM2 provide this option already? (BTW, thanks for the quick response.) – Glen Mazza Jul 03 '13 at 16:18

1 Answers1

0

I came up with a simple solution:

I created a subclass of AbstractXMLOutputProcessor with attributeEscapedEntitiesFilter() overridden to no longer check of output escaping is disabled: http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-war/src/main/java/org/apache/wiki/render/CustomXMLOutputProcessor.java?revision=1499446&view=markup

...and then linked it into the XMLOutputter (line 62): http://svn.apache.org/viewvc/incubator/jspwiki/trunk/jspwiki-war/src/main/java/org/apache/wiki/render/XHTMLRenderer.java?revision=1499446&view=markup#l62

Works fine now.

Glen Mazza
  • 748
  • 1
  • 6
  • 27
  • Excellent, I am pleased you found it easy to override the class in the way you wanted. This is a validation for me that the API was set up 'right'. I have been looking for some sort of specification for the escaping PI, and come up short. I don't know what the right answer is. This fix of yours will work well for you. If you do the outputting often you may want to make the custom class a static final instance.... may compile better (JIT). – rolfl Jul 03 '13 at 16:39