Message:
The following issue has been resolved as WON'T FIX.
Resolver: Michael Glavassevich
Date: Tue, 1 Jun 2004 10:46 AM
There's a historical reason for this behaviour. A default error handler [1] was
created some time ago to address the concerns of users who claimed that the parser was
broken because they were not receiving notification of validation errors.
I had a chat with some other Xerces-J developers and we noted that regardless of what
the parser does in this situation, some users won't like the behaviour: either
reporting nothing or writing to System.err. I wasn't involved in the project when the
decision to start printing error messages to the console was made, however I believe
the developers were aware of the tradeoff. The change that was made to print to
System.err requires that a no-op error handler be installed to 'quiet' the default
behaviour.
[1]
http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/src/org/apache/xerces/util/DefaultErrorHandler.java?rev=1.1.2.1&view=markup
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/XERCESJ-972
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XERCESJ-972
Summary: Problem using Xerces with Xinetd sockets
Type: Bug
Status: Resolved
Priority: Major
Resolution: WON'T FIX
Project: Xerces2-J
Versions:
2.6.2
Assignee:
Reporter: Bilari
Created: Sun, 30 May 2004 11:54 PM
Updated: Tue, 1 Jun 2004 10:46 AM
Environment: Redhat Linux Enterprise Linux Server version 3 on i686.
Description:
I downloaded the source code for Xerces-J. It is strewn with System.out.println and
System.err.println. This is all very nice for debug purposes, but there are major
complications when an application relies on Xinetd to invoke itself.
Xinetd invokes the application and passes the socket input stream and output stream to
System.in and System.out respectively. So when in the Xerces code, System.out or
System.err is executed, in the context of an application invoked via Xinetd, it
actually performs a write on the Socket and hence to the invoking application. This is
a very tricky issue and I have temporarily fixed it by calling:
DOMParser.setProperty("error-handler",null).
But I dont think this is a very elegant way of doing it. So I request you to consider
the fact that it is a VERY bad idea of having System.outs or System.errs in the code.
Use proper Logging. Log4J is good, but it also has System.outs and System.errs in its
code.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
