axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad A. Chodavarapu (JIRA)" <>
Subject [jira] Created: (AXIS-2163) Horrendous implementation of DOM APIs, especially those dealing with Attribute Nodes, in org.apache.axis.message
Date Wed, 03 Aug 2005 19:45:36 GMT
Horrendous implementation of DOM APIs, especially those dealing with Attribute Nodes, in org.apache.axis.message

         Key: AXIS-2163
     Project: Apache Axis
        Type: Bug
    Versions: 1.2    
 Environment: Sun JDK 1.5.0-b64
    Reporter: Prasad A. Chodavarapu
    Priority: Blocker
 Attachments: axis-dom.patch

There are two classes of problems in the implementation of
W3C DOM APIs in org.apache.axis.message. 

1) Easy one first: Tons of bugs in code dealing with
   attribute creation and retrieval using W3C DOM APIs. Two
   sub-classes of problems here.

     a) Mistakes easy to spot by simple visual inspection of
        the code. Mistakes like:

           if(namespaceURI.equals(attr.getNamespaceURI()) &&

     b) Terrible confusion over how to represent the absence
        of a namespace. Mix up of three different values:
        null, "" and "intentionalNullURI". 

2) Real problem: SAAJ mandates that implementations
   concurrently provide two different DOM APIs - a SOAP
   specific one and the general purpose W3C DOM API. 
   W3C DOM APIs are awful in quite a few respects and
   definitely, it's a lot of work to implement all the W3C
   mandated methods. But implementing them correctly is
   important because generic XML infrastructure such as
   XPath interpreters and (Apache) XML Security assume
   W3C DOM.

   The problem is that Axis takes a bad shortcut that really
   hurts anyone depending on other generic XML libs that
   assume a W3C DOM. Instead of implementing all of the W3C DOM
   APIs, org.apache.axis.message.SOAPDocumentImpl uses a
   second dummy W3C DOM Document, to "delegate" some (but
   not all) of the W3C DOM API calls.

   While ELEMENT nodes seem to be implemented using the
   MessageElement class (tying them into the SOAP specific
   DOM), attribute nodes are created in a dummy W3C DOM

   This does not work because, when some one
   invokes a method like getAttributes() (defined in
   NodeImpl, a super class of MessageElement - an
   implementation of SAAJ SOAPElement), the Attribute nodes
   found in the returned NamedNodeMap are not from the
   same DOM in which the element nodes are defined! 
   This plays havoc with XPath interpreters and XML Security

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message