[jdom-interest] Namespace declaration "gets lost"
Laurent Bihanic
laurent.bihanic at atosorigin.com
Wed Oct 16 04:54:01 PDT 2002
Hi,
I had a quick look at SAXHandler code and it seems the bug lay in the use of
List.removeAll(Collection) in endElement (see line
availableNamespaces.removeAll(addl);).
IMHO, the scenario is the following: After the second declaration, your
namespace appears twice in the list of available namespaces (good) and also as
an additional namespace for the current element (good too). When processing
the endElement event, SAXHandler removes all the additional namespaces of the
"ended" element from the list of available namespaces using List.removeAll.
This method removes *all* occurrences of the objects contained in the
collection passed as argument. Hence the two namespace declaration are removed
(bad!).
Later on, when encountering the "returnvalue" attribute, SAXHandler fails to
resolve the namespace and uses NO_NAMESPACE instead (bad too!) (see method
getNamespace).
Questions :
1. Why does endElement() remove the additional namespaces from the list of
available namespaces ? SAX dedicates this task to endPrefixMapping and
SAXHandler.endPrefixMapping does it perfectly.
2. Why does getNamespace silently absorb attempts to match unknown prefixes?
This would be acceptable when the prefix does not reference a namespace but
this case is not handled by this method (see test on
attQName.equals(attLocalName) in startElement).
Stefan, as a temporary fix, you should delete/comment out the following lines
from SAXHandler.endElement() and rebuild jdom.jar:
// Remove the namespaces that this element makes available
List addl = element.getAdditionalNamespaces();
if (addl.size() > 0) {
availableNamespaces.removeAll(addl);
This will let the underlying XML parser decide when a namespace prefix goes
out of scope rather than having JDOM do it.
Hope this helps,
Laurent
Liebig, Stefan wrote:
> Hi,
>
> When parsing the following XML document with JDOM_beta8 and trying to
> "analyze" it´s
> content, it seems that after the second (redundant but legal, or?) "ino"
> namesspace
> decl. JDOM gets confused.
>
> <?xml version="1.0" encoding="utf-8" ?>
> <ino:response xmlns:ino="http://namespaces.softwareag.com/tamino/response2"
> xmlns:xql="http://metalab.unc.edu/xql/">
> <xql:query>
> testUpdate_sli[@ino:id=1]
> </xql:query>
> <ino:message ino:returnvalue="0">
> <ino:messageline>
> XQL Request processing
> </ino:messageline>
> </ino:message>
> <xql:result>
> <testUpdate_sli ino:id="1"
> xmlns:ino="http://namespaces.softwareag.com/tamino/response2">
> DOC: -1
> </testUpdate_sli>
> </xql:result>
> <ino:message ino:returnvalue="0">
> <ino:messageline>
> XQL Request processed
> </ino:messageline>
> </ino:message>
> </ino:response>
>
> When running the attached JunitTest the output shows the following:
>
> Next message tag
> AttributesList:[[Attribute: ino:returnvalue="0"]]
> Attribute.name:returnvalue
> Attribute.value:0
> Attribute.getNS:[Namespace: prefix "ino" is mapped to URI
> "http://namespaces.softwareag.com/tamino/response2"]
> ReturnValue:0
> text: XQL Request processing
> Next message tag
> AttributesList:[[Attribute: returnvalue="0"]]
> Attribute.name:returnvalue
> Attribute.value:0
> Attribute.getNS:[Namespace: prefix "" is mapped to URI ""]
> ReturnValue:null
> text: XQL Request processed
>
> As you can see the second message element has "lost" it´s namespace
> and so the "ino:returnvalue" can not be evaluated correctly.
> BTW, with Xerces/DOM it is evaluated correctly.
>
> Stefan
More information about the jdom-interest
mailing list