The following comment has been added to this issue:
Author: elharo
Created: Tue, 8 Jun 2004 6:47 AM
Body:
You're right, of course. A new method is clearly the wrong solution to this problem.
However, we still do need a non-system wide, implementation independent way to specify
this on a single parser object. Therefore, I propose doing it with a SAX property such
as http://apache.org/xml/properties/parser-configuration
This would allow you to do something like
try {
parser.setProperty("http://apache.org/xml/properties/parser-configuration";, new
MyParserConfiguration());
}
catch (SAXException ex) {
// must not be Xerces; skip it
}
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/XERCESJ-976?page=comments#action_35970
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/XERCESJ-976
Here is an overview of the issue:
---------------------------------------------------------------------
Key: XERCESJ-976
Summary: System properties should not be used to configure parser
Type: Improvement
Status: Unassigned
Priority: Major
Project: Xerces2-J
Components:
XNI
Versions:
2.6.2
Assignee:
Reporter: elharo
Created: Thu, 3 Jun 2004 8:51 AM
Updated: Tue, 8 Jun 2004 6:47 AM
Environment: All
Description:
The use of system properties to configure the parser is a major problem in many
environments. In particular the org.apache.xerces.xni.parser.XMLParserConfiguration
is causing major troubles. Among these:
1. It is impossible to set this property in an applet environment due to security
restrictions.
2. While this property can be set in a server-side environment, it then affects all
classes loaded on the server, even those loaded by a different class loader which may
not have access to the class org.apache.xerces.xni.parser.XMLParserConfiguration
points to. Setting this property in one servlet can break otehr servlets that also
dependn on Xerces.
3. Different parser objects used for different purposes may require different
configurations. This is not possible when one system property controls them all.
A *method* such as setParserConfiguration() should be provided that replaces this
system property. Furthermore, this method should have object-scope rather than
system-scope so it's possible for different applications running in the same VM as is
common in server environment, to configure their parsers differently. Several XOM
users have reported different problems that all trace back to this system property and
its global scope.
---------------------------------------------------------------------
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]
