Bug 6607 - bug on ElementNode2.getAttributeNodeNS
Summary: bug on ElementNode2.getAttributeNodeNS
Status: VERIFIED FIXED
Alias: None
Product: Crimson
Classification: Unclassified
Component: other (show other bugs)
Version: 1.1
Hardware: All All
: P3 blocker with 2 votes (vote)
Target Milestone: ---
Assignee: Edwin Goei
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-21 10:19 UTC by Christophe Jolif
Modified: 2004-11-16 19:05 UTC (History)
1 user (show)



Attachments
patch allowing "null"-namespaceURIs in Element.getAttributeNS (1.08 KB, patch)
2002-04-11 16:07 UTC, Clemens Klein-Robbenhaar
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christophe Jolif 2002-02-21 10:19:32 UTC
The following small test case crashes with crimson (cvs snapshot):

import org.w3c.dom.*;

import org.apache.crimson.tree.*;

public class BugB
{
    // CJO 02/2002
    public static void main(String[] arg) {
    // directly create XmlDocument just for the prupose
    // of having a smaller test...
        XmlDocument doc = new XmlDocument();
        Element elt = doc.createElementNS(null, "foo");
        doc.appendChild(elt);
        elt.setAttributeNS(null, "bar", "bar_value");
    // this line should not return the previous
    // element has the namespace is not the same
    // but it should not crash either...
        elt.getAttributeNS("myNS", "bar");
    }
}
Comment 1 Clemens Klein-Robbenhaar 2002-04-11 16:04:34 UTC
The problem is caused by the fact that the code does not expect
someone mixing namespaces with non-namespaces.
 if the requested namespace is not null, the code silently
expects all namespaces of the node attributes to be not null,
and sends them messages without null - checks ...

 i will upload a small patch here that will fix the problem
in this place. the code is not-so-efficient afterwards
because it always sends an "equals" to the namespace-strings,
while mostly an "==" should give the right anwer.
 i guess to keep the code efficient one should write two
loops in the affected method; one for null and one for non-null
arguments, to avoid repetetive tests for null / not null within
the loop. (i have made no performance measurements; i think the
performance loss if my patch is neglegible ... but who knows ...)

 by the way: is passing "null" argument as namespaceURI legal anyway?

if one changes the test case from:

 elt.setAttributeNS(null, "bar", "bar_value");

to

 elt.setAttribute( "bar", "bar_value");

no exception happens. 

 If "null" namespaces are not allowed 
(the w3c DOM-spec says nothing about it, because it is defined
in IDL, wich does not case about Java "null"; but seems reasonable
to me, that namespaces should not be null),
 this bug report is invalid and the patch obsolete.

 Instead one should throw an exception in "setAttributeNS" instead
(which happens already now, if the attribute name contains namespace
definition; change:

 elt.setAttributeNS(null, "bar", "bar_value");

to:

 elt.setAttributeNS(null, "foo:bar", "bar_value");

to see the exception.
Comment 2 Clemens Klein-Robbenhaar 2002-04-11 16:07:01 UTC
Created attachment 1523 [details]
patch allowing "null"-namespaceURIs in Element.getAttributeNS
Comment 3 Christophe Jolif 2002-04-11 16:15:05 UTC
FYI, a <null> namespace is perfectly conformant to W3C DOM. So this have to be
fixed. From DOM Level 2 recommendation:

"Applications must use the value null as the namespaceURI parameter for methods
if they wish to have no namespace."
Comment 4 Clemens Klein-Robbenhaar 2002-04-11 21:31:13 UTC
 Er, Christophe is right ... I should have read the spec before
make statements about it :(