DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5461>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5461 DefaultEntityHandler.expandSystemID() returns "", causes JAXP 1.1 violation in xalan Summary: DefaultEntityHandler.expandSystemID() returns "", causes JAXP 1.1 violation in xalan Product: Xerces-J Version: 1.4.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: JAXP AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I'm seeing a problem where javax.xml.transform.sax.SAXSource, getSystemId() is retuning "", where the Sun JAXP 1.1 CTS tests are expecting a null return. I'm opening this bug against xerces, but I could easily be convinced that xalan is at fault. I'm using: xerces-J 1.4.4 xalan ?? (it's the version that comes with Sun's 1.1.3 xml-java pack) Windows 2k, Intel Here's a bottom-up description of what is happening. org/apache/xerces/readers/DefaultEntityHandler.java, in expandSystemId(), returns the empty string ("") when passed a null systemId. The comment here looks like somebody was concerned about this change. org/apache/xerces/parsers/SAXParser.java, in startDocument(), calls setDocumentLocator() on the content handler, passing in a DefaultEntityHandler instance as the sole argument. In xalan (org/apache/xalan/processor/StylesheelHandler.java, in setDocumentLocator()), the DefaultEntityHandler (which implements Locator) is used when constructing a new SAXSourceLocator(). In xalan's org/apache/xml/utils/SAXSourceLocator ctor, it sets its systemId member varibale from Locator.getSystemId(). SAXSourceLocator's super-interface, javax.xml.transform.sax.SourceLocator, is spec'ed to return null from getSystemId(). It's irritating that javax.xml.transform.Source is spec'ed to return null if setSystemId has not been called. It would be really nice if the two interfaces agreed. A potential fix to this individual problem is to have the SAXSourceLocator ctor check to see if ("".equals(locator.getSystemId()) and set the systemId to null. I'm just concerned that the "" return expandSystemId() back up in the DefaultEntityHandler will cause problems in other areas. Sorry to have marked this as a blocker, but for any J2EE 1.3 vendor that wants to use xerces instead of crimson as the JAXP 1.1 compliant parser, this problem needs to be fixed. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
