You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Todor Todorov (JIRA)" <ji...@codehaus.org> on 2008/02/11 15:36:28 UTC

[jira] Created: (SUREFIRE-455) XML delimiter characters in attribute and text content are escaped twice.

XML delimiter characters in attribute and text content are escaped twice. 
--------------------------------------------------------------------------

                 Key: SUREFIRE-455
                 URL: http://jira.codehaus.org/browse/SUREFIRE-455
             Project: Maven Surefire
          Issue Type: Bug
          Components: xml generation
    Affects Versions: 2.4.1, 2.4
            Reporter: Todor Todorov
         Attachments: surefire-api.patch

XML delimiter characters (left angle bracket, ampersand, etc.) are escaped twice in _TEST-*.xml_ files in _surefire-reports_ directory. For example the left angle bracket is replaced with &amp;lt; instead of &lt; and the right angle bracket with &amp;gt; instead of &gt;

{code:xml}
  <testcase time="2.306" classname="MyTest" name="testItem">
    <failure message="expected:&amp;lt;10&amp;gt; but was:&amp;lt;7&amp;gt;" type="junit.framework.AssertionFailedError">
junit.framework.AssertionFailedError: expected:&amp;lt;10&amp;gt; but was:&amp;lt;7&amp;gt;
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotSame(Assert.java:278)
        at junit.framework.Assert.assertSame(Assert.java:242)
        at MyTest.testItem(MyTest.java:38)
    </failure>
  </testcase>
{code}

The problem is that both *org.apache.maven.surefire.report.XMLReporter* and *org.apache.maven.surefire.util.PrettyPrintXMLWriter* are escaping the XML content. As a result the ampersand character is escaped once more time. In addition *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* has implementation error: three characters (ampersand, left angle bracket and right angle bracket) are replaced with *&amp;amp;*

In the attached patch (for surefire-2.4.1) I removed *org.apache.maven.surefire.report.XMLReporter#escapeAttribute* method and fixed *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* implementation. Afterwards the XML report was generated as expected:

{code:xml}
  <testcase time="2.306" classname="MyTest" name="testItem">
    <failure message="expected:&lt;10&gt; but was:&lt;7&gt;" type="junit.framework.AssertionFailedError">
junit.framework.AssertionFailedError: expected:&lt;10&gt; but was:&lt;7&gt;
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.failNotSame(Assert.java:278)
        at junit.framework.Assert.assertSame(Assert.java:242)
        at MyTest.testItem(MyTest.java:38)
    </failure>
  </testcase>
{code}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Commented: (SUREFIRE-455) XML delimiter characters in attribute and text content are escaped twice.

Posted by "Todor Todorov (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/SUREFIRE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123399 ] 

Todor Todorov commented on SUREFIRE-455:
----------------------------------------

Thanks for your fast reaction. I agree, throwing information away is a bad idea. In my test case I need a string delimiter and I use _null_ character. It is unusual, but if the string contains XML fragments, it is a good choice I think. I filtered only the _null_ character, because I read by mistake [XML 1.1 Specification|http://www.w3.org/TR/xml11/#charsets]. It extends the character range with {{RestrictedChar}} set, so _null_ is probably the only bad character left there.

> XML delimiter characters in attribute and text content are escaped twice. 
> --------------------------------------------------------------------------
>
>                 Key: SUREFIRE-455
>                 URL: http://jira.codehaus.org/browse/SUREFIRE-455
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: xml generation
>    Affects Versions: 2.4, 2.4.1
>            Reporter: Todor Todorov
>             Fix For: 2.4.2
>
>         Attachments: surefire-api.patch
>
>
> XML delimiter characters (left angle bracket, ampersand, etc.) are escaped twice in _TEST-*.xml_ files in _surefire-reports_ directory. For example the left angle bracket is replaced with &amp;lt; instead of &lt; and the right angle bracket with &amp;gt; instead of &gt;
> {code:xml}
>   <testcase time="2.306" classname="MyTest" name="testItem">
>     <failure message="expected:&amp;lt;10&amp;gt; but was:&amp;lt;7&amp;gt;" type="junit.framework.AssertionFailedError">
> junit.framework.AssertionFailedError: expected:&amp;lt;10&amp;gt; but was:&amp;lt;7&amp;gt;
>         at junit.framework.Assert.fail(Assert.java:47)
>         at junit.framework.Assert.failNotSame(Assert.java:278)
>         at junit.framework.Assert.assertSame(Assert.java:242)
>         at MyTest.testItem(MyTest.java:38)
>     </failure>
>   </testcase>
> {code}
> The problem is that both *org.apache.maven.surefire.report.XMLReporter* and *org.apache.maven.surefire.util.PrettyPrintXMLWriter* are escaping the XML content. As a result the ampersand character is escaped once more time. In addition *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* has implementation error: three characters (ampersand, left angle bracket and right angle bracket) are replaced with *&amp;amp;*
> In the attached patch (for surefire-2.4.1) I removed *org.apache.maven.surefire.report.XMLReporter#escapeAttribute* method and fixed *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* implementation. Afterwards the XML report was generated as expected:
> {code:xml}
>   <testcase time="2.306" classname="MyTest" name="testItem">
>     <failure message="expected:&lt;10&gt; but was:&lt;7&gt;" type="junit.framework.AssertionFailedError">
> junit.framework.AssertionFailedError: expected:&lt;10&gt; but was:&lt;7&gt;
>         at junit.framework.Assert.fail(Assert.java:47)
>         at junit.framework.Assert.failNotSame(Assert.java:278)
>         at junit.framework.Assert.assertSame(Assert.java:242)
>         at MyTest.testItem(MyTest.java:38)
>     </failure>
>   </testcase>
> {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Closed: (SUREFIRE-455) XML delimiter characters in attribute and text content are escaped twice.

Posted by "Dan Fabulich (JIRA)" <ji...@codehaus.org>.
     [ http://jira.codehaus.org/browse/SUREFIRE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Fabulich closed SUREFIRE-455.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.4.2

Thanks for your work here.  We actually have an integration test for this that verified XML validity, but it didn't catch this case (I examined the XML by eye and it looked fine).  I've enhanced the integration test to examine the messages explicitly to catch this case.

Interestingly, this highlighted a bug in the way we handle non-visible control characters (e.g. the null charater \0).  You added code to explicitly filter out null characters in your patch.  That was a reasonable choice, but I decided that we didn't want to throw away information.  Also, it's not just nulls; all non-visible control characters except for \t \n and \r are invalid in XML 1.0, even in entity form.  So I deliberately introduced SUREFIRE-456 to handle this case.

Submitted revision 620660.

> XML delimiter characters in attribute and text content are escaped twice. 
> --------------------------------------------------------------------------
>
>                 Key: SUREFIRE-455
>                 URL: http://jira.codehaus.org/browse/SUREFIRE-455
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: xml generation
>    Affects Versions: 2.4, 2.4.1
>            Reporter: Todor Todorov
>             Fix For: 2.4.2
>
>         Attachments: surefire-api.patch
>
>
> XML delimiter characters (left angle bracket, ampersand, etc.) are escaped twice in _TEST-*.xml_ files in _surefire-reports_ directory. For example the left angle bracket is replaced with &amp;lt; instead of &lt; and the right angle bracket with &amp;gt; instead of &gt;
> {code:xml}
>   <testcase time="2.306" classname="MyTest" name="testItem">
>     <failure message="expected:&amp;lt;10&amp;gt; but was:&amp;lt;7&amp;gt;" type="junit.framework.AssertionFailedError">
> junit.framework.AssertionFailedError: expected:&amp;lt;10&amp;gt; but was:&amp;lt;7&amp;gt;
>         at junit.framework.Assert.fail(Assert.java:47)
>         at junit.framework.Assert.failNotSame(Assert.java:278)
>         at junit.framework.Assert.assertSame(Assert.java:242)
>         at MyTest.testItem(MyTest.java:38)
>     </failure>
>   </testcase>
> {code}
> The problem is that both *org.apache.maven.surefire.report.XMLReporter* and *org.apache.maven.surefire.util.PrettyPrintXMLWriter* are escaping the XML content. As a result the ampersand character is escaped once more time. In addition *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* has implementation error: three characters (ampersand, left angle bracket and right angle bracket) are replaced with *&amp;amp;*
> In the attached patch (for surefire-2.4.1) I removed *org.apache.maven.surefire.report.XMLReporter#escapeAttribute* method and fixed *org.apache.maven.surefire.util.PrettyPrintXMLWriter#escapeXml* implementation. Afterwards the XML report was generated as expected:
> {code:xml}
>   <testcase time="2.306" classname="MyTest" name="testItem">
>     <failure message="expected:&lt;10&gt; but was:&lt;7&gt;" type="junit.framework.AssertionFailedError">
> junit.framework.AssertionFailedError: expected:&lt;10&gt; but was:&lt;7&gt;
>         at junit.framework.Assert.fail(Assert.java:47)
>         at junit.framework.Assert.failNotSame(Assert.java:278)
>         at junit.framework.Assert.assertSame(Assert.java:242)
>         at MyTest.testItem(MyTest.java:38)
>     </failure>
>   </testcase>
> {code}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira