You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by R J Scheuerle Jr <sc...@us.ibm.com> on 2006/02/14 00:15:33 UTC
[Axis2] Question about Axis 2 SAAJ implementation
Consider the following code from the SOAPElementTest:
final String value = "foo";
soapElem.addTextNode(value);
I should be able to get the javax.xml.soap.Node using several different
accessors (getChildElements(), getChildNodes(), getFirstChild()), etc.
------------------------------
Problem 1:
Object x = soapElem.getChildElements().next();
Object y = soapElem.getChildElements().next();
In this case, x and y are both javax.xml.soap.Node objects (good); however
they are not the same object. The iterator is constructing new objects
each time it is invoked. This is not efficient and incorrect.
-------------------------------
Problem 2
Object z1 = soapElem.getChildNodes().item(0);
Object z2 = soapElem.getFirstChild();
In both cases, the returned object is not an SAAJ javax.xml.soap.Node.
This also seems to be a violation of the specification.
===========================
The proposed solution is to clearly separate the SAAJ implementation from
the "backing" axis2.om.impl.dom tree.
The SAAJ layer is a semantic view of the underlying DOM model. Thus it
should always return SAAJ objects when its methods are invoked.
Comments ?
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
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me...where is the patch :) Did you forget to include it in the
email :) :)
Welcome back!!
-- dims
On 2/13/06, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
>
>
>
> Consider the following code from the SOAPElementTest:
>
> final String value = "foo";
> soapElem.addTextNode(value);
>
> I should be able to get the javax.xml.soap.Node using several different
> accessors (getChildElements(), getChildNodes(), getFirstChild()), etc.
>
> ------------------------------
> Problem 1:
> Object x = soapElem.getChildElements().next();
> Object y = soapElem.getChildElements().next();
>
> In this case, x and y are both javax.xml.soap.Node objects (good); however
> they are not the same object. The iterator is constructing new objects each
> time it is invoked. This is not efficient and incorrect.
>
> -------------------------------
> Problem 2
> Object z1 = soapElem.getChildNodes().item(0);
> Object z2 = soapElem.getFirstChild();
>
> In both cases, the returned object is not an SAAJ javax.xml.soap.Node. This
> also seems to be a violation of the specification.
>
> ===========================
> The proposed solution is to clearly separate the SAAJ implementation from
> the "backing" axis2.om.impl.dom tree.
> The SAAJ layer is a semantic view of the underlying DOM model. Thus it
> should always return SAAJ objects when its methods are invoked.
>
>
> Comments ?
>
> Rich Scheuerle
> Senior Developer
> IBM WebSphere Web Services Engine & Tooling
> 512-838-5115 (IBM TL 678-5115)
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by Changshin Lee <ia...@gmail.com>.
2006. 02. 14, 오전 8:15, R J Scheuerle Jr 작성:
>
> Consider the following code from the SOAPElementTest:
>
> final String value = "foo";
> soapElem.addTextNode(value);
>
> I should be able to get the javax.xml.soap.Node using several
> different accessors (getChildElements(), getChildNodes(),
> getFirstChild()), etc.
>
> ------------------------------
> Problem 1:
> Object x = soapElem.getChildElements().next();
> Object y = soapElem.getChildElements().next();
>
> In this case, x and y are both javax.xml.soap.Node objects (good);
> however they are not the same object. The iterator is constructing
> new objects each time it is invoked. This is not efficient and
> incorrect.
soapElem.getChildElements() returns an Iterator, therefore its first
next() and second next() should return different objects. Please make
sure that Iterator.next() is not a plain accessor but designed to use
traversing over collections.
>
> -------------------------------
> Problem 2
> Object z1 = soapElem.getChildNodes().item(0);
> Object z2 = soapElem.getFirstChild();
>
> In both cases, the returned object is not an SAAJ
> javax.xml.soap.Node. This also seems to be a violation of the
> specification.
Could you tell us exactly what type is z1 and z2? I also guess those
returned objects belong to OM package, not DOOM package.
Thanks,
Ias
>
> ===========================
> The proposed solution is to clearly separate the SAAJ
> implementation from the "backing" axis2.om.impl.dom tree.
> The SAAJ layer is a semantic view of the underlying DOM model. Thus
> it should always return SAAJ objects when its methods are invoked.
>
>
> Comments ?
>
> 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
Posted by Afkham Azeez <af...@gmail.com>.
On second thoughts, interface javax.xml.soap.Node extends
org.w3c.dom.Node, hence I agree that wherever we return
org.w3c.dom.Node, we should return javax.xml.soap.Node & not
org.apache.axis2.om.impl.dom.NodeImpl, in order to be spec compliant.
Regards
Azeez
On 2/14/06, Afkham Azeez <af...@gmail.com> wrote:
> >
> > Consider the following code from the SOAPElementTest:
> >
> > final String value = "foo";
> > soapElem.addTextNode(value);
> >
> > I should be able to get the javax.xml.soap.Node using several
> > different accessors (getChildElements(), getChildNodes(),
> > getFirstChild()), etc.
> >
> > ------------------------------
> > Problem 1:
> > Object x = soapElem.getChildElements().next();
> > Object y = soapElem.getChildElements().next();
> >
> > In this case, x and y are both javax.xml.soap.Node objects (good);
> > however they are not the same object. The iterator is constructing
> > new objects each time it is invoked. This is not efficient and
> > incorrect.
>
> I agree with Ias on this point. Only if you call
> soapElem.getChildElements(), new objects will be created.
>
> >
> > -------------------------------
> > Problem 2
> > Object z1 = soapElem.getChildNodes().item(0);
> > Object z2 = soapElem.getFirstChild();
> >
> > In both cases, the returned object is not an SAAJ
> > javax.xml.soap.Node. This also seems to be a violation of the
> > specification.
> Note that the javax.xml.SOAPElement extends org.w3c.dom.Node. The
> getChildNodes() and getFirstChild() methods are inherited from the
> org.w3c.dom.Node interface. Hence we cannot return javax.xml.soap.Node
> objects from these methods. For instance, the method signature of
> getFirstChild() is;
> public org.w3c.dom.Node getFirstChild();
> So now we can see that, we cannot return javax.xml.soap.Node objects.
> In order to use only SAAJ interfaces, you need to use the methods that
> are directly in the javax.xml.SOAPElement interface.
>
> Regards
> Azeez
>
--
Thanks
Afkham Azeez
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by Davanum Srinivas <da...@gmail.com>.
Rich,
You *AND* all committers belonging to ws have read-write access to
*ALL* ws projects including Axis2. Just tread gently :)
thanks,
dims
On 2/14/06, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
>
>
> >>
> >> Consider the following code from the SOAPElementTest:
> >>
> >> final String value = "foo";
> >> soapElem.addTextNode(value);
> >>
> >> I should be able to get the javax.xml.soap.Node using several
> >> different accessors (getChildElements(), getChildNodes(),
> >> getFirstChild()), etc.
> >>
> >> ------------------------------
> >> Problem 1:
> >> Object x = soapElem.getChildElements().next();
> >> Object y = soapElem.getChildElements().next();
> >>
> >> In this case, x and y are both javax.xml.soap.Node objects (good);
> >> however they are not the same object. The iterator is constructing
> >> new objects each time it is invoked. This is not efficient and
> >> incorrect.
>
> >Afkham said:
> >I agree with Ias on this point. Only if you call
> >soapElem.getChildElements(), new objects will be created.
>
> Scheu response:
> Thanks Afkham.
> 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.
>
>
> >>
> >> -------------------------------
> >> Problem 2
> >> Object z1 = soapElem.getChildNodes().item(0);
> >> Object z2 = soapElem.getFirstChild();
> >>
> >> In both cases, the returned object is not an SAAJ
> >> javax.xml.soap.Node. This also seems to be a violation of the
> >> specification.
>
> >Afkham said:
> >Note that the javax.xml.SOAPElement extends org.w3c.dom.Node. The
> >getChildNodes() and getFirstChild() methods are inherited from the
> >org.w3c.dom.Node interface. Hence we cannot return javax.xml.soap.Node
> >objects from these methods. For instance, the method signature of
> >getFirstChild() is;
> > public org.w3c.dom.Node getFirstChild();
> >So now we can see that, we cannot return javax.xml.soap.Node objects.
> >In order to use only SAAJ interfaces, you need to use the methods that
> >are directly in the javax.xml.SOAPElement interface.
>
> 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).
>
> 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.
>
> 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).
>
> Here is a view of the proposed model:
>
> Initially we have a SOAPBody (view) that has uses DOOM as the backing store
> (delegate).
>
>
> --------------- ----------------
> | SOAPBody | -------delegate-------> | OM Element |
> --------------- <--------view---------- ----------------
> | |
> -------------
> -------------
> | OM Element| - | OM
> Element|
> -------------
> -------------
>
> The SOAPBody.getFirstChild() method is invoked. The getFirstChild() method
> implementation should look
> something like this.
>
> getSOAPBody() {
> // Get the object representing the first child from the delegate
> doomNode = delegate.getFirstChild();
>
> // If the doom node already has an SAAJ view, then use it.
> // Otherwise create one
> org.w3c.saaj.Node node =
> getOrCreateSAAJNodeFromDOOMNode(doomNode);
>
> return node;
> }
>
> The result of calling this method is:
>
>
> --------------- ----------------
> | SOAPBody | -------delegate-------> | OM Element |
> --------------- <--------view---------- ----------------
> | |
> ------------------ -------------
> -------------
> | SOAPBodyElement| ----delegate----> | OM Element| - | OM
> Element|
> ------------------ <-----view------- -------------
> -------------
>
> Important notes:
> 1) The SAAJ objects are lightweight view objects onto the DOOM tree.
> 2) All hierarchy information is maintained in the DOOM tree. There are no
> pointers between SAAJ objects.
> 3) The SAAJ objects are lazily instantiated.
>
> Comments ?
>
>
>
>
>
> Rich Scheuerle
> Senior Developer
> IBM WebSphere Web Services Engine & Tooling
> 512-838-5115 (IBM TL 678-5115)
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Rich,
>
> I am suggesting that an SAAJ node is lightweight delegates to a DOOM node
> (which is very similar to the current design). I am also suggesting that
> the DOOM node have a back pointer to its corresponding SAAJ node (this is
> missing in the current design).
Regarding DOOM node having a back pointer to SAAJ node: In that case
do you mean that DOOM has to be aware of SAAJ?
IMHO this is not possible since DOOM is meant to be clean DOM impl
which also implements the OM interfaces. This is a requirement for
Axis2 to support integration of the WSS4J based security module.
thanks,
Ruchith
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2006-02-16 at 09:13 -0600, R J Scheuerle Jr wrote:
> I agree that DOOM should not reference SAAJ. The suggestion is that
> the backpointer is an Object.
Sure.. like a userData field which is totally in the purview of the
user. +1.
Sanjiva.
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
> Sanjiva said:
> -1 to this .. DOOM shouldn't know anything about SAAJ - that's just a
> DOM impl over OM. Why do we need this? We need to find another way to
> address this need ..
I agree that DOOM should not reference SAAJ. The suggestion is that the
backpointer is an Object.
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
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, 2006-02-16 at 06:37 -0600, R J Scheuerle Jr wrote:
>
> I am suggesting that an SAAJ node is lightweight delegates to a DOOM
> node (which is very similar to the current design). I am also
OK.
> suggesting that the DOOM node have a back pointer to its
> corresponding SAAJ node (this is missing in the current design).
-1 to this .. DOOM shouldn't know anything about SAAJ - that's just a
DOM impl over OM. Why do we need this? We need to find another way to
address this need ..
Sanjiva.
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
>> The SOAPBody.getFirstChild() method is invoked. The getFirstChild()
method
>> implementation should look
>> something like this.
>>
>> getSOAPBody() {
>> // Get the object representing the first child from the delegate
>> doomNode = delegate.getFirstChild();
>>
>> // If the doom node already has an SAAJ view, then use it.
>> // Otherwise create one
>> org.w3c.saaj.Node node =
>> getOrCreateSAAJNodeFromDOOMNode(doomNode);
>>
>> return node;
>> }
>So you are suggesting that we should cache the SAAJ Nodes? May be we
>can maintain a Map between SAAJ Nodes and DOOM nodes, any thoughts on
>this?
I am suggesting that an SAAJ node is lightweight delegates to a DOOM node
(which is very similar to the current design). I am also suggesting that
the DOOM node have a back pointer to its corresponding SAAJ node (this is
missing in the current design).
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
Posted by Afkham Azeez <af...@gmail.com>.
> The SOAPBody.getFirstChild() method is invoked. The getFirstChild() method
> implementation should look
> something like this.
>
> getSOAPBody() {
> // Get the object representing the first child from the delegate
> doomNode = delegate.getFirstChild();
>
> // If the doom node already has an SAAJ view, then use it.
> // Otherwise create one
> org.w3c.saaj.Node node =
> getOrCreateSAAJNodeFromDOOMNode(doomNode);
>
> return node;
> }
So you are suggesting that we should cache the SAAJ Nodes? May be we
can maintain a Map between SAAJ Nodes and DOOM nodes, any thoughts on
this?
> Important notes:
> 1) The SAAJ objects are lightweight view objects onto the DOOM tree.
Agreed
> 2) All hierarchy information is maintained in the DOOM tree. There are no
> pointers between SAAJ objects.
This is how it has been currently implemented.
> 3) The SAAJ objects are lazily instantiated.
Again, we'll have to maintain a cache for this purpose (a Map between
DOOM Nodes and SAAJ Nodes?)
--
Thanks
Afkham Azeez
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
>> 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
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2006-02-14 at 07:42 -0600, R J Scheuerle Jr wrote:
> 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.
Bye,
Sanjiva.
Re: [Axis2] Question about Axis 2 SAAJ implementation
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
>>
>> Consider the following code from the SOAPElementTest:
>>
>> final String value = "foo";
>> soapElem.addTextNode(value);
>>
>> I should be able to get the javax.xml.soap.Node using several
>> different accessors (getChildElements(), getChildNodes(),
>> getFirstChild()), etc.
>>
>> ------------------------------
>> Problem 1:
>> Object x = soapElem.getChildElements().next();
>> Object y = soapElem.getChildElements().next();
>>
>> In this case, x and y are both javax.xml.soap.Node objects (good);
>> however they are not the same object. The iterator is constructing
>> new objects each time it is invoked. This is not efficient and
>> incorrect.
>Afkham said:
>I agree with Ias on this point. Only if you call
>soapElem.getChildElements(), new objects will be created.
Scheu response:
Thanks Afkham.
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.
>>
>> -------------------------------
>> Problem 2
>> Object z1 = soapElem.getChildNodes().item(0);
>> Object z2 = soapElem.getFirstChild();
>>
>> In both cases, the returned object is not an SAAJ
>> javax.xml.soap.Node. This also seems to be a violation of the
>> specification.
>Afkham said:
>Note that the javax.xml.SOAPElement extends org.w3c.dom.Node. The
>getChildNodes() and getFirstChild() methods are inherited from the
>org.w3c.dom.Node interface. Hence we cannot return javax.xml.soap.Node
>objects from these methods. For instance, the method signature of
>getFirstChild() is;
> public org.w3c.dom.Node getFirstChild();
>So now we can see that, we cannot return javax.xml.soap.Node objects.
>In order to use only SAAJ interfaces, you need to use the methods that
>are directly in the javax.xml.SOAPElement interface.
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).
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.
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).
Here is a view of the proposed model:
Initially we have a SOAPBody (view) that has uses DOOM as the backing store
(delegate).
--------------- ----------------
| SOAPBody | -------delegate-------> | OM Element |
--------------- <--------view---------- ----------------
| |
-------------
-------------
| OM Element| - | OM
Element|
-------------
-------------
The SOAPBody.getFirstChild() method is invoked. The getFirstChild() method
implementation should look
something like this.
getSOAPBody() {
// Get the object representing the first child from the delegate
doomNode = delegate.getFirstChild();
// If the doom node already has an SAAJ view, then use it.
// Otherwise create one
org.w3c.saaj.Node node = getOrCreateSAAJNodeFromDOOMNode(doomNode);
return node;
}
The result of calling this method is:
--------------- ----------------
| SOAPBody | -------delegate-------> | OM Element |
--------------- <--------view---------- ----------------
| |
------------------ -------------
-------------
| SOAPBodyElement| ----delegate----> | OM Element| - | OM
Element|
------------------ <-----view------- -------------
-------------
Important notes:
1) The SAAJ objects are lightweight view objects onto the DOOM tree.
2) All hierarchy information is maintained in the DOOM tree. There are no
pointers between SAAJ objects.
3) The SAAJ objects are lazily instantiated.
Comments ?
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
Posted by Afkham Azeez <af...@gmail.com>.
>
> Consider the following code from the SOAPElementTest:
>
> final String value = "foo";
> soapElem.addTextNode(value);
>
> I should be able to get the javax.xml.soap.Node using several
> different accessors (getChildElements(), getChildNodes(),
> getFirstChild()), etc.
>
> ------------------------------
> Problem 1:
> Object x = soapElem.getChildElements().next();
> Object y = soapElem.getChildElements().next();
>
> In this case, x and y are both javax.xml.soap.Node objects (good);
> however they are not the same object. The iterator is constructing
> new objects each time it is invoked. This is not efficient and
> incorrect.
I agree with Ias on this point. Only if you call
soapElem.getChildElements(), new objects will be created.
>
> -------------------------------
> Problem 2
> Object z1 = soapElem.getChildNodes().item(0);
> Object z2 = soapElem.getFirstChild();
>
> In both cases, the returned object is not an SAAJ
> javax.xml.soap.Node. This also seems to be a violation of the
> specification.
Note that the javax.xml.SOAPElement extends org.w3c.dom.Node. The
getChildNodes() and getFirstChild() methods are inherited from the
org.w3c.dom.Node interface. Hence we cannot return javax.xml.soap.Node
objects from these methods. For instance, the method signature of
getFirstChild() is;
public org.w3c.dom.Node getFirstChild();
So now we can see that, we cannot return javax.xml.soap.Node objects.
In order to use only SAAJ interfaces, you need to use the methods that
are directly in the javax.xml.SOAPElement interface.
Regards
Azeez