ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 49404] XMLJUnitResultFormatter does not encode entity/character references
Date Tue, 15 Jun 2010 04:04:09 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=49404

--- Comment #7 from Mark Lassau <mlassau@atlassian.com> 2010-06-15 00:04:04 EDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > by now there may or may not be code that relies on the current behavior.
> 
> That's always possible, but the current behavior is known to be wrong, and
> directly contradicts the Javadoc for the encode method.

Looking at the code, I have to agree with Jesse.

The isReference() check is basically saying "if the value parameter looks like
it was already encoded, then don't encode it again".
I imagine that someone added this when they saw behaviour that was
double-encoding a given string.
ie Some code was calling encode() twice (this is a bug). Instead of fixing that
bug, they put a "safety mechanism" in the encode() method.

Now the problem with this "safety mechanism" is that it is broken when you
legitimately want to encode an entity reference.

It seems to me that the "correct" fix would be to remove the isReference()
check and fix any code that wants to call this method twice.
If this is considered too hard or too risky, then could you create a new
implementation (eg called "encodeXml()" ) which will work correctly for Strings
with entity references?
You could then update the javadoc on the old method to clearly identify its
behaviour, and possibly even deprecate it.

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

Mime
View raw message