DO NOT REPLY [Bug 6283] New: - NPE: System id for external dtd is not passed to DefaultHandler.resolveEntity.

[bu...@apache.org]

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=6283>.
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=6283

NPE: System id for external dtd is not passed to DefaultHandler.resolveEntity.

           Summary: NPE: System id for external dtd is not passed to
                    DefaultHandler.resolveEntity.
           Product: Xerces2-J
           Version: 2.0.0
          Platform: All
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: SAX
        AssignedTo: xerces-j-dev@xml.apache.org
        ReportedBy: gleichtman@bioimaging.com
                CC: gleichtman@bioimaging.com


Jetty 4D4 reads an XML configuration file in order to set up container 
properties. The beginning of this file is as follows:

<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure SYSTEM "dtd/configure.dtd">
...

When Xerces 2J jars are substituted for Jetty's Jaxp and Crimson jars, a null 
pointer exception is caused that does not occur with Jaxp/Crimson. The 
traceback for the NPE masks where the actual problem occurs. Below is a 
traceback for where the NPE is actually generated:

- resolveEntity(): 277, org.mortbay.xml.XmlParser$Handler, XmlParser.java
- resolveEntity(): 138, org.apache.xerces.util.EntityResolverWrapper, 
EntityResolverWrapper.java
- esolveEntity(): 528,org.apache.xerces.impl.XMLEntityManager, 
XMLEntityManager.java
- dispatch(): 809, org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher, 
XMLDocumentScannerImpl.java
- scanDocument(): 333, org.apache.xerces.impl.XMLDocumentFragmentScannerImpl, 
XMLDocumentFragmentScannerImpl.java
- parse(): 525, org.apache.xerces.parsers.StandardParserConfiguration, 
StandardParserConfiguration.java
- parse(): 581, org.apache.xerces.parsers.StandardParserConfiguration, 
StandardParserConfiguration.java
- parse(): 147, org.apache.xerces.parsers.XMLParser, XMLParser.java
- parse(): 1157, org.apache.xerces.parsers.AbstractSAXParser, 
AbstractSAXParser.java
- parse(): 345, javax.xml.parsers.SAXParser, SAXParser.java
- parse(): 223, javax.xml.parsers.SAXParser, SAXParser.java
- parse(): 109, org.mortbay.xml.XmlParser, XmlParser.java
- <init>: 97, org.mortbay.xml.XmlConfiguration, XmlConfiguration.java
- <init> 82, org.mortbay.jetty.Server, Server.java
- <init> 57, org.mortbay.jetty.Server, Server.java
...

The NPE occurs in Jetty at:

- resolveEntity(): 277, org.mortbay.xml.XmlParser$Handler, XmlParser.java

where Jetty attempts to use the system id---the external DTD path. 
Unfortunately, Jetty has been passed a null for the system id and this leads to 
the NPE.

An analysis of the Xerces 2J code that causes this problem follows:

Here is the code in the dispatch method shown in the trace above:

...
case SCANNER_STATE_DTD_EXTERNAL: {
  resourceIdentifier.setValues(fDoctypePublicId, fDoctypeSystemId, null, null);
  XMLInputSource xmlInputSource = fEntityManager.resolveEntity
(resourceIdentifier);
...

Notice the invocation: resourceIdentifier.setValues(fDoctypePublicId, 
fDoctypeSystemId, null, null);

The signature for setValues is:

    public void setValues(String publicId, String literalSystemId,
                          String baseSystemId, String expandedSystemId) 

The method setValues is defined in 
org.apache.xerces.util.XMLResourceIdentifierImpl.java.

Notice that null is being passed for the expandedSystemId.

Now, notice the following code from 
org.apache.xerces.util.EntityResolverWrapper.resolveEntity:

                InputSource inputSource = 
                    fEntityResolver.resolveEntity(resourceIdentifier.getPublicId
(), resourceIdentifier.getExpandedSystemId());


Notice that resourceIdentifier.getExpandedSystemId() is being passed for the 
system id. Since the expanded system id is hard coded at null with setValues, 
the system id will NEVER be passed on to the resolve entity method of the 
implementing class, namely the Jetty code in this case.

Note that DefaultHandler.resolveEntity IS meant to be overridden based upon the 
JavaDoc provided:

    /**
     * Resolve an external entity.
     *
     * <p>Always return null, so that the parser will use the system
     * identifier provided in the XML document.  This method implements
     * the SAX default behaviour: application writers can override it
     * in a subclass to do special translations such as catalog lookups
     * or URI redirection.</p>
     *
     * @param publicId The public identifer, or null if none is
     *                 available.
     * @param systemId The system identifier provided in the XML 
     *                 document.
     * @return The new input source, or null to require the
     *         default behaviour.
     * @exception org.xml.sax.SAXException Any SAX exception, possibly
     *            wrapping another exception.
     * @see org.xml.sax.EntityResolver#resolveEntity
     */
    public InputSource resolveEntity (String publicId, String systemId)
	throws SAXException
    {
	return null;
    }


Jetty is overriding this method, yet it is not being passed the system id, so 
it crashes.

Therefore, I believe that this is a bug in Xerces 2J, since the system id will 
never be passed on to a class that overrides resolveEntity for the 
org.xml.sax.helpers.DefaultHandler. This problem currently makes it impossible 
to use Jetty with Xerces 2J, something that we would like to do, since the rest 
of our code base uses Xerces.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org