-
Bug
-
Resolution: Unresolved
-
P4
-
1.4.0, 7
-
Cause Known
-
x86
-
linux, windows_2000
Name: gm110360 Date: 09/05/2002
FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
This bug is not OS dependant
A DESCRIPTION OF THE PROBLEM :
java.util.logging.XMLFormatter is capable of outputting
characters that are banned by the XML spec, specifically
those below \u0020.
\u0009, \u000a and \000d are allowed by the XML spec but
other characters < \0020 are illegal and will cause most
parsers to fail. There is no reason why the LogRecord
passed to format() should not have these characters in its
member strings, so it should be up the the XMLFormatter
(probably the escape() function) to throw an exception or
translate the characters.
The encoding (e.g. utf-8) has little bearing on this issue,
as these xml-illegal low-value characters ARE VALID IN UTF-
8 and are left untouched by ASCII -> utf-8 conversion.
I am aware that there are other ranges of characters that
are illegal in XML, but it was these low-value characters
that brought this bug to my attention.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Configure any handler to use the XMLFormatter.
2.Log a message containing illegal characters e.g. \u0012
3.Attempt to parse the resulting XML output
EXPECTED VERSUS ACTUAL BEHAVIOR :
The XMLFormatter.format() function should either throw an
exception when it encounters illegal characters or
(possibly better) translate them into something harmless.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.logging.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import java.io.*;
class XMLFormatterBugTest {
private static Logger logger = Logger.getLogger("XMLFormatterBugTest");
public static void main(String[] args) throws Exception{
FileHandler ch = new FileHandler("invalid.xml", false);
ch.setFormatter(new XMLFormatter());
logger.addHandler(ch);
logger.info("This message will result in valid XML.");
logger.severe("This one [\u0012] won't!");
ch.close();
//logger.dtd must exist in the working directory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setValidating(false);
DocumentBuilder db = dbf.newDocumentBuilder();
Document dom = db.parse(new File("invalid.xml"));
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
It's not too hard to reimplement XMLFormatter to work
properly, but escape() is private, so you have to rewrite
the whole class.
(Review ID: 164079)
======================================================================
FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
This bug is not OS dependant
A DESCRIPTION OF THE PROBLEM :
java.util.logging.XMLFormatter is capable of outputting
characters that are banned by the XML spec, specifically
those below \u0020.
\u0009, \u000a and \000d are allowed by the XML spec but
other characters < \0020 are illegal and will cause most
parsers to fail. There is no reason why the LogRecord
passed to format() should not have these characters in its
member strings, so it should be up the the XMLFormatter
(probably the escape() function) to throw an exception or
translate the characters.
The encoding (e.g. utf-8) has little bearing on this issue,
as these xml-illegal low-value characters ARE VALID IN UTF-
8 and are left untouched by ASCII -> utf-8 conversion.
I am aware that there are other ranges of characters that
are illegal in XML, but it was these low-value characters
that brought this bug to my attention.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Configure any handler to use the XMLFormatter.
2.Log a message containing illegal characters e.g. \u0012
3.Attempt to parse the resulting XML output
EXPECTED VERSUS ACTUAL BEHAVIOR :
The XMLFormatter.format() function should either throw an
exception when it encounters illegal characters or
(possibly better) translate them into something harmless.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.logging.*;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import java.io.*;
class XMLFormatterBugTest {
private static Logger logger = Logger.getLogger("XMLFormatterBugTest");
public static void main(String[] args) throws Exception{
FileHandler ch = new FileHandler("invalid.xml", false);
ch.setFormatter(new XMLFormatter());
logger.addHandler(ch);
logger.info("This message will result in valid XML.");
logger.severe("This one [\u0012] won't!");
ch.close();
//logger.dtd must exist in the working directory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setValidating(false);
DocumentBuilder db = dbf.newDocumentBuilder();
Document dom = db.parse(new File("invalid.xml"));
}
}
---------- END SOURCE ----------
CUSTOMER WORKAROUND :
It's not too hard to reimplement XMLFormatter to work
properly, but escape() is private, so you have to rewrite
the whole class.
(Review ID: 164079)
======================================================================
- duplicates
-
JDK-6511588 XMLFormatter does not handle non-XML-safe characters
-
- Closed
-