DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=27516>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=27516 Xalan-J 2.5.2 fails reading Encoding.properties Summary: Xalan-J 2.5.2 fails reading Encoding.properties Product: XalanJ2 Version: 2.5 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: org.apache.xalan.serialize AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Xalan-J 2.5.2 fails to initialize correctly when called from JUnitReport in a ant build file. For some mysterious reasons, it fails to setup the serialization TextStream, when it attempts to initialize its supported encoding. In ant, it produces an Initializer exception, and debug/verbose output indicates that this is caused by attempting to parse an integer from a string which really is part of a comment indicating the HTTP url of the IANA charset database. This string should not be parsed as an integer, and it seems that the XalanJ uses its own code to parse a encoding.properties file embedded in xalan.jar, and forgets to ignore comment lines. The problem is when parsing this line in the jar-embedded Encodings.properties. This bug occurs at least when using the newer Java 1.5, as if comment lines in properties files were no more detected (possibly a problem of text format for this properties file) Reverting to XalanJ 2.5.1 solves this problem. Something has changed in the way Xalan initialize its supported encodings, or something is already bogous in XalanJ 2.5.1 even though its codepath currently does not read its embedded Encoding.properties file which also contains comment lines. Note that the Encoding.properties file is not the same between XalanJ 2.5.1 and XalanJ 2.5.2, that's why I think it's a problem of text format for the properties file embedded in XalanJ 2.5.2 (a Mac format? a Unix format which parses incorrectly under Windows?)
