>> 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)
- Re: [Axis2] Question about Axis 2 SAAJ implementation R J Scheuerle Jr
- Re: [Axis2] Question about Axis 2 SAAJ implementa... Ruchith Fernando
- Re: [Axis2] Question about Axis 2 SAAJ implementa... Sanjiva Weerawarana
- Re: [Axis2] Question about Axis 2 SAAJ implem... R J Scheuerle Jr
- Re: [Axis2] Question about Axis 2 SAAJ im... Sanjiva Weerawarana
- Re: [Axis2] Question about Axis 2 SAAJ implementa... R J Scheuerle Jr
