Scott --
It's because of what it does.
DTMDefaultBase.declareNamespaceInContext is responsible for populating
two collections:
m_namespaceDeclSets is a vector each of whose elements is a
SuballocatedIntVector. Each entry in the vector represents a distinct
namespace environment and contains a list of the namespace nodes in
effect at that point.
m_namespaceDeclSetElements is s SuballocatedIntVector in its own right.
Each entry contains the node index of the node where that environment
takes effect.
When a new entry is created in m_namespaceDeclSets, any inherited
namespaces are recorded there. The code checks for the possibility
that, at this node, a previously declared prefix has been redeclared.
It does this by looking up the "expanded type" of current namespace
node. The expanded type of the current namespace node is an integer
subdivided into three parts: a type (which is 2 for an attribute node),
a namespace (which is 1, representing the namespace for namespaces), and
a local name. If it finds a match for this prefix in the existing
table, it replaces it. Otherwise, it adds it. Under the old code, the
expanded type for the new namespace node had not yet been set so it was
always zero. The one exception was in this case where the node index
was 2048 and it exceeded the length of the preallocated array for the
SuballocatedIntVector which is why we got the NPE. Anyway, in the
normal case, the code would pick up zero. This would, of course, never
match the entries in the existing m_namespaceDeclSets sublist so the
namespace would always be added. So, we could have a list representing
nodes that looked like this:
xmlns:foo="http://top.level";
xmlns:bar="http://next.level";
xmlns:foo="http://another.level";
The problem was that I couldn't find a place where this array was
actually used for anything that mattered. It probably is but I just
couldn't find it because it was late at night and this was my first
excursion into the bowels of the DOM2DTM as well as the DTM.
In order to get the namespace URI, DOM2DTM refers back to the actual DOM
node which was, of course, unaffected by any of this DTM stuff. I never
got to the code that actually emitted the namespace declarations on the
result tree which was the only place that I figured this might actually
matter but every example I tried seemed to work okay. So, since I was
late and I knew that the change was simply changing the
declareNamespaceInContext() invocation until after the namespace
attribute was actually declared, I committed the change and sent the
message to this list.
Perhaps you or Joe or someone more familiar with how this list is used
could create a test case that would highlight this problem and then I
could see where it mattered. We could test the change against 2.2.D6
versus the current CVS and make sure that it gave different results to
validate that it was a good test.
This was especially wierd because when the DOM was serialized and then
run through XalanJ again everything worked. This was because the new
version went through SAX2DTM which had the declareNamespaceInContext()
in the right place in the addNode() routine. So, just looking at the
XML in a text file wouldn't show you any difference between the working
and non-working versions.
Gary
[EMAIL PROTECTED] wrote:
>
> > XalanJ was
> > trying to determine a value for a namespace declaration before the value
> > was set.
>
> Wow. We have several tests that build a stylesheet from a DOM. Why wasn't
> this caught?
>
> -scott
>
>
> Gary L Peskin
> <garyp@firste To: [EMAIL PROTECTED]
> ch.com> cc: (bcc: Scott Boag/CAM/Lotus)
> Subject: Re: AW: [Xalan-J 2.2.0D6]:
>Strange problems with DOM and
> 07/13/01 XPath
> 04:22 AM
> Please
> respond to
> xalan-dev
>
>
>
> Carsten --
>
> I have uploaded a fix to CVS for this strange problem. XalanJ was
> trying to determine a value for a namespace declaration before the value
> was set. Thanks much for your persistence in this. I appreciate the
> work involved in migrating from DOM Level 1 to DOM Level 2 in your
> application even though the problem still presented itself after you
> made that change. Oh well, at least you've got an up-to-date
> application now.
>
> Thanks,
> Gary
>
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > it took us some time to make the shift from dom level 1 to dom level 2,
> > but we made it. Now our dom contains only dom level 2 nodes (or it
> > should as none of the level 1 methods is called by us).
> >
> > But unfortunatly the problem still exists. Attached is the serialized
> dom,
> > perhaps it helps in finding the problem.
> >
> > The exception I get is the following
> >
> > java.lang.NullPointerException
> > at
> >
> org.apache.xml.utils.SuballocatedIntVector.elementAt(SuballocatedIntVector.j
>
> > ava:440)
> > at org.apache.xml.dtm.ref.DTMDefaultBase.
> _exptype(DTMDefaultBase.java:485)
> > at
> >
> org.apache.xml.dtm.ref.DTMDefaultBase.getExpandedTypeID(DTMDefaultBase.java:
>
> > 1362)
> > at
> >
> org.apache.xml.dtm.ref.DTMDefaultBase.declareNamespaceInContext(DTMDefaultBa
>
> > se.java:1044)
> > at
> org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.addNode(DOM2DTM.java:213)
> > at
> org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.nextNode(DOM2DTM.java:507)
> > at org.apache.xml.dtm.ref.DTMDefaultBase.
> _nextsib(DTMDefaultBase.java:579)
> > at
> >
> org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$ChildTraverser.next(DTMDefau
>
> > ltBaseTraversers.java:462)
> > at
> org.apache.xpath.axes.AxesWalker.getNextNode(AxesWalker.java:354)
> > at org.apache.xpath.axes.AxesWalker.nextNode(AxesWalker.java:385)
> > at
> org.apache.xpath.axes.WalkingIterator.nextNode(WalkingIterator.java:182)
> > at
> org.apache.xpath.axes.LocPathIterator.runTo(LocPathIterator.java:802)
> > at
> org.apache.xml.dtm.ref.DTMNodeList.<init>(DTMNodeList.java:114)
> > at org.apache.xpath.objects.XNodeSet.nodelist(XNodeSet.java:349)
> > at org.apache.xpath.XPathAPI.selectNodeList(XPathAPI.java:205)
> > at org.apache.xpath.XPathAPI.selectNodeList(XPathAPI.java:182)
> >
> > Carsten
> >
> > Open Source Group sunShine - b:Integrated
> > ================================================================
> > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > www.sundn.de mailto: [EMAIL PROTECTED]
> > ================================================================
> >
> > > -----Ursprungliche Nachricht-----
> > > Von: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Mittwoch, 11. Juli 2001 11:08
> > > An: [EMAIL PROTECTED]
> > > Betreff: Re: AW: [Xalan-J 2.2.0D6]: Strange problems with DOM and XPath
> > >
> > >
> > > Carsten --
> > >
> > > This is discussed in
> > > http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#
> > > Namespaces-Considerations
> > >
> > > In particular, "Note that because the DOM does no lexical checking, the
> > > empty string will be treated as a real namespace URI in DOM Level 2
> > > methods. Applications must use the value null as the namespaceURI
> > > parameter for methods if they wish to have no namespace."
> > >
> > > Change your getAttributeNS call to getAttributeNS(null, "name") and see
> > > what happens.
> > >
> > > Gary
> > >
> > >
> > > Carsten Ziegeler wrote:
> > > >
> > > > Hi Gary,
> > > >
> > > > just a quick question to very things:
> > > >
> > > > We changed now all methods to their equivalents with the ending "NS".
> > > > If we now want to retrieve an attribute which has no namespace,
> > > > we use the element method "getAttributeNS("", "name"). However
> > > > this returns the empty string whereas "getAttribute("name") works.
> > > >
> > > > Is this a bug in the getAttributeNS() method? I read (now) the
> > > > dom level 2 spec about this, but I think it is now very clear
> > > > about this point:
> > > >
> > > > >>>>
> > > > getAttributeNS introduced in DOM Level 2
> > > > Retrieves an attribute value by local name and namespace URI.
> > > HTML-only DOM
> > > > implementations do not need to implement this method.
> > > > Parameters
> > > > namespaceURI of type DOMString
> > > > The namespace URI of the attribute to retrieve.
> > > >
> > > > localName of type DOMString
> > > > The local name of the attribute to retrieve.
> > > >
> > > > Return Value
> > > > DOMString
> > > > The Attr value as a string, or the empty string if that
> > > attribute does not
> > > > have a specified or default value.
> > > >
> > > > No Exceptions
> > > > <<<<<
> > > >
> > > > Carsten
> > > >
> > > > > -----Ursprungliche Nachricht-----
> > > > > Von: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> > > > > Gesendet: Mittwoch, 11. Juli 2001 10:09
> > > > > An: [EMAIL PROTECTED]
> > > > > Betreff: Re: AW: [Xalan-J 2.2.0D6]: Strange problems with DOM
> > > and XPath
> > > > >
> > > > >
> > > > > Carsten --
> > > > >
> > > > > I'm not claiming that it is -not- a bug in XalanJ2. I'm just
> > > suggesting
> > > > > that if the DOM stuff gets cleaned up and the bug is still
> > > there, we'll
> > > > > look for it.
> > > > >
> > > > > Gary
> > > > >
> > > > > Carsten Ziegeler wrote:
> > > > > >
> > > > > > Hi Gary,
> > > > > >
> > > > > > sorry for blaming Xalan-J again for a not existing bug. Our
> > > developers
> > > > > > should really read the DOM spec first...(our should do it...)
> > > > > >
> > > > > > But thank you for this hint, we are currently rewriting our
> > > applications
> > > > > > and will test it over the next days.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Carsten
> > > > > >
> > > > > > > -----Ursprungliche Nachricht-----
> > > > > > > Von: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> > > > > > > Gesendet: Dienstag, 10. Juli 2001 20:49
> > > > > > > An: [EMAIL PROTECTED]
> > > > > > > Betreff: Re: AW: [Xalan-J 2.2.0D6]: Strange problems with DOM
> > > > > and XPath
> > > > > > >
> > > > > > >
> > > > > > > Carsten --
> > > > > > >
> > > > > > > I deserialized your attachment and noticed that it mixes
> > > DOM Level 1
> > > > > > > nodes (ElementImpl) with Level 2 nodes (ElementNSImpl).
> > > Since things
> > > > > > > work when you serialize and then reparse, I suspect that
> > > > > DOM2DTM is not
> > > > > > > handling this situation as you expect. The DOM spec does
> > > say "mixing
> > > > > > > both sets of methods can lead to unpredictable results"
> > > and it seems
> > > > > > > like that is what's happening.
> > > > > > >
> > > > > > > If possible, try to rewrite your application so that you are
> > > > > using only
> > > > > > > the NS forms of the various DOM APIs and then see if you
> > > can reproduce
> > > > > > > your problem.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > Carsten Ziegeler wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I know that it is hard to find but I have absolutely no clue
> how
> > > > > > > > to build a test case.
> > > > > > > >
> > > > > > > > I know do the following: If the XPathAPI throws this
> > > NPE, I catch
> > > > > > > > the exception, serialize the complete document to a string
> and
> > > > > > > > then reparse it, creating a clean DOM and invoke then the
> > > > > > > > XPathAPI again. And this works.
> > > > > > > >
> > > > > > > > I serialized the document and attached it to the mail. I hope
> > > > > > > > this helps you.
> > > > > > > >
> > > > > > > > (I didn't test if it is reproducable by deserialization).
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Carsten
> > > > > > > >
> > > > > > > > Open Source Group sunShine -
> b:Integrated
> > > > > > > >
> ================================================================
> > > > > > > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100
> Paderborn
> > > > > > > > www.sundn.de mailto:
> [EMAIL PROTECTED]
> > > > > > > >
> ================================================================
> > > > > > > >
> > > > > > > > > -----Ursprungliche Nachricht-----
> > > > > > > > > Von: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]
> > > > > > > > Gesendet: Freitag, 6. Juli 2001 15:31
> > > > > > > > An: [EMAIL PROTECTED]
> > > > > > > > Betreff: Re: [Xalan-J 2.2.0D6]: Strange problems with
> > > DOM and XPath
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > The problem is happening during incremental construction of
> > > > > > the DTM model.
> > > > > > > > It's trying to retrieve information which has not yet
> > > been stored,
> > > > > > > > specifically, the expanded type information for a node which
> > > > > > hasn't yet
> > > > > > > > been written into the tables. But unless we can provoke
> > > it under a
> > > > > > > > debugger, I really can't tell whether this is because it's
> > > > > > referencing a
> > > > > > > > node that hasn't yet been created, or a node which has been
> > > > > > > > created but not
> > > > > > > > initialized properly. Neither, of course, should be
> happening.
> > > > > > > >
> > > > > > > > I've got one off-the-cuff guess... The DOM permits using
> > > > > > > > namespaces without
> > > > > > > > ever declaring them. It's possible that you're creating this
> > > > > > > > situation, and
> > > > > > > > that our DOM2DTM code isn't handling it properly. We
> > > could try a few
> > > > > > > > examples and see if we can reproduce the problem that way...
> > > > > > > >
> > > > > > > > ... but if there's any way you can come up with a reliably
> > > > > > reproducable
> > > > > > > > testcase -- maybe add code to catch that exception and
> > > > > > serialize out the
> > > > > > > > DOM which is provoking it, though serializing might wind up
> > > > > > masking the
> > > > > > > > problem? -- that'd be tremendously helpful.
> > > > > > > >
> >
> >
> ------------------------------------------------------------------------
> > Name: domser.zip
> > domser.zip Type: Zip Compressed Data (application/x-zip-compressed)
> > Encoding: base64
