You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by ji...@apache.org on 2004/05/31 08:56:00 UTC
[jira] Created: (XERCESJ-972) Problem using Xerces with Xinetd sockets
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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: Unassigned
Priority: Major
Project: Xerces2-J
Versions:
2.6.2
Assignee:
Reporter: Bilari
Created: Sun, 30 May 2004 11:54 PM
Updated: Sun, 30 May 2004 11:54 PM
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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
[jira] Resolved: (XERCESJ-972) Problem using Xerces with Xinetd sockets
Posted by ji...@apache.org.
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: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org