axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From R J Scheuerle Jr <sc...@us.ibm.com>
Subject Re: [Axis2] Question about Axis 2 SAAJ implementation
Date Thu, 16 Feb 2006 13:09:11 GMT
>> The Iterator returned by getChildElements should traverse the actual
>> soap.Node objects in the tree.  One should be able to use the iterator
>> to add to the tree.  The iterator should also support removal of the
>> elements.  The iterator could be used frequently by callers and the
>> implementation; thus it should not be creating new proxy objects
>> representing the soap.Node objects.

>Are you stating SAAJ requirements or design preferences? AFAIK there's
>no requirement that the iterator return the actual nodes; did I miss
>something?

>> My response:
>>
>> Yes, per the SAAJ 1.2 specification, the SOAPElement interface extends
>> the org.w3c.dom.Element interface.
>> This revision of the specification allows you to access the SAAJ tree
>> using traditional DOM methods.
>> It also allows the SAAJ tree to be treated like a DOM tree.
>>
> Note that javax.xml.soap.Node extends org.w3c.dom.Node.
>>
>> If this is a SAAJ tree, the getFirstChild method should return a
>> org.w3c.dom.Node which is also a valid object in the SAAJ tree (which
>> means that it must also be a javax.xml.soap.Node).

>Right, but you must upcast to get it into a javax.xml.soap.Node, right?
>If so I'm confused as to what is broken.

>> If one has a SOAPBody object and accesses a child node (via any of the
>> SAAJ 1.2 methods), the child node must be either a
>> javax.xml.soap.SOAPBodyElement, javax.xml.soap.SOAPFault or
>> javax.xml.soap.Text object.

>Or rather, a DOM Node which can be upcast to one of the above, no?

>> dims asked "where's the patch":
>>
>> My response:
>> There are several "phases" of changes that are needed to move to this
>> model.  I could add all of them as one large patch, but I am more
>> comfortable with adding the changes gradually (with testcases).  What
>> do I need to do to become a committer (I was a committer for Axis
>> 1.0).

>I'm confused about what exactly is broken .. can you please elaborate a
>bit more?

>W.r.t. commits, please try to make incremental changes .. or if its a
>major change let's make sure its discussed and agreed to here before
>moving forward.

I will try to answer the questions with a simple example.
Suppose I have the following snippet of XML.

<soapenv:Body>
  <request/>
  </request>
</soapenv:/Body>

In the current Axis 2.0 architecture this is represented by the following
object tree.

 -------------              ---------------------
 | SOAPBody  | -----------> | DOOM soapenv:Body |
 -------------              ---------------------
                                       |
                            ---------------------
                            | DOOM request      |
                            ---------------------

When one calls body.getChildElements().next(), the implementation creates
and returns a new SOAPElement node.
Problem 1: This is a spec concern.  The returned node is a SOAPElement. It
should be a SOAPBodyElement since the children of SOAPBody must be
SOAPBodyElements or javax.xml.soap.Text.

 -------------              ---------------------
 | SOAPBody  | -----------> | DOOM soapenv:Body |
 -------------              ---------------------
                                       |
 -------------------        ---------------------
 | SOAPElement (1) |------->| DOOM request      |
 -------------------        ---------------------

If you call body.getChildElements().next() again, the implementation
creates and returns a completely new SOAPElement.
Problem 2: This is a design concern.  Creating additional elements is not
performant and unexpected.


 -------------              ---------------------
 | SOAPBody  | -----------> | DOOM soapenv:Body |
 -------------              ---------------------
                                       |
 -------------------        ---------------------
 | SOAPElement (2) |------->| DOOM request      |
 -------------------        ---------------------

If you call body.getFirstChild(), the implementation returns the "DOOM
request" object.
Problem 3: This is a specification concern.  The children of a SOAPBody
must be SOAPBodyElements or javax.xml.Text objects.


 -------------              ---------------------
 | SOAPBody  | -----------> | DOOM soapenv:Body |
 -------------              ---------------------
                                       |
                            ---------------------
                            | DOOM request      |
                            ---------------------

The proposed solution is to enhance the code to support a backpointer from
the DOOM node to the SOAPElement node.
The proposed architecture cleanly separates the tree model (DOOM) from the
view onto the tree model (SAAJ).
I also think the proposed change scales easily for the other methods (i.e.
inserting SAAJ/DOM nodes into the tree).

 -------------               ---------------------
 | SOAPBody  | <-----------> | DOOM soapenv:Body |
 -------------               ---------------------
                                       |
 ------------------          ---------------------
 | SOAPBodyElement| <----->  | DOOM request      |
 ------------------          ---------------------

I would like to here your comments.  I have been implementing SAAJ models
for the past few years.

Rich Scheuerle
Senior Developer
IBM WebSphere Web Services Engine & Tooling
512-838-5115  (IBM TL 678-5115)
Mime
View raw message