You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2007/04/03 07:52:43 UTC

Re: [axiom] [axis2] getChildrenWithName() erroneous behavior

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,



Glen Daniels wrote:
> Hi all:
> 
> Currently OMElement.getChildrenWithName(QName) uses the
> OMChildrenQNameIterator to walk the list of children and return matches.
>  Here's the problem - if there is no namespace (or no localName...
> luckily that part isn't possible), the iterator will happily match ANY
> element with a matching localName.  So for instance when we do this:
> 
> config_element.getChildrenWithName(new QName("transportSender"))
> 
> We'll get both <axisCfg:transportSender> and
> <extension:transportSender>.  This is bad.  The above API call SHOULD
> only match <transportSender> in no namespace.

I did this purposely and I wanted to get matching nodes when I am not
sure about the namespace. The idea I had in mind was, say if I have a
SOAP message and and if I wanted to see whether the body contains a
fault, then I can use the above method without worrying about which
version of SOAP I am dealing with.

But if you want to clean this method and create another method, I'm ok
with that too. But please please make sure we have
OMElement.getChildrenWithLocalName(String). I am a poor user which needs
that.

Thanks,
Chinthaka
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGEeurjON2uBzUhh8RAgRUAJwIm0ZvAg2a+lS+1HrtISinHivcngCcDFSo
tkZktx6rum7LcbNbnklabLk=
=i/C7
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [axiom] [axis2] getChildrenWithName() erroneous behavior

Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Chinthaka!

Eran Chinthaka wrote:
>> Currently OMElement.getChildrenWithName(QName) uses the
>> OMChildrenQNameIterator to walk the list of children and return matches.
>>  Here's the problem - if there is no namespace (or no localName...
>> luckily that part isn't possible), the iterator will happily match ANY
>> element with a matching localName.  So for instance when we do this:
>>
>> config_element.getChildrenWithName(new QName("transportSender"))
>>
>> We'll get both <axisCfg:transportSender> and
>> <extension:transportSender>.  This is bad.  The above API call SHOULD
>> only match <transportSender> in no namespace.
> 
> I did this purposely and I wanted to get matching nodes when I am not
> sure about the namespace. The idea I had in mind was, say if I have a
> SOAP message and and if I wanted to see whether the body contains a
> fault, then I can use the above method without worrying about which
> version of SOAP I am dealing with.

Unfortunately, XML is namespace aware, and if you're going to be using 
it, ESPECIALLY as the author of infrastructure code that is expected to 
be industrial-strength, you need to be rigorous about namespaces.  If 
you wrote code like you describe and got this:

<soap:Envelope>
   <soap:Body>
     <myGeologyApp:Fault name="San Andreas">
       <customData/>
     </myGeologyApp:Fault>
   </soap:Body>
</soap:Envelope>

...then that would be recognized as a SOAP fault (which wouldn't parse 
right anyway) and your poor user might not ever be able to receive their 
geological information.  There were a LOT of problems that were hidden 
in OM because of this kind of non-namespace-aware comparison.

> But if you want to clean this method and create another method, I'm ok
> with that too. But please please make sure we have
> OMElement.getChildrenWithLocalName(String). I am a poor user which needs
> that.

Sure, but our code really shouldn't be using it... :)

--Glen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org


Re: [axiom] [axis2] getChildrenWithName() erroneous behavior

Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Chinthaka!

Eran Chinthaka wrote:
>> Currently OMElement.getChildrenWithName(QName) uses the
>> OMChildrenQNameIterator to walk the list of children and return matches.
>>  Here's the problem - if there is no namespace (or no localName...
>> luckily that part isn't possible), the iterator will happily match ANY
>> element with a matching localName.  So for instance when we do this:
>>
>> config_element.getChildrenWithName(new QName("transportSender"))
>>
>> We'll get both <axisCfg:transportSender> and
>> <extension:transportSender>.  This is bad.  The above API call SHOULD
>> only match <transportSender> in no namespace.
> 
> I did this purposely and I wanted to get matching nodes when I am not
> sure about the namespace. The idea I had in mind was, say if I have a
> SOAP message and and if I wanted to see whether the body contains a
> fault, then I can use the above method without worrying about which
> version of SOAP I am dealing with.

Unfortunately, XML is namespace aware, and if you're going to be using 
it, ESPECIALLY as the author of infrastructure code that is expected to 
be industrial-strength, you need to be rigorous about namespaces.  If 
you wrote code like you describe and got this:

<soap:Envelope>
   <soap:Body>
     <myGeologyApp:Fault name="San Andreas">
       <customData/>
     </myGeologyApp:Fault>
   </soap:Body>
</soap:Envelope>

...then that would be recognized as a SOAP fault (which wouldn't parse 
right anyway) and your poor user might not ever be able to receive their 
geological information.  There were a LOT of problems that were hidden 
in OM because of this kind of non-namespace-aware comparison.

> But if you want to clean this method and create another method, I'm ok
> with that too. But please please make sure we have
> OMElement.getChildrenWithLocalName(String). I am a poor user which needs
> that.

Sure, but our code really shouldn't be using it... :)

--Glen

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org