Thanks Gary for your quick help in fixing this!
I just tried it out and it works absolutly great!
(Forget my previous email about the try/catch block,
I send it about 15 minutes before I received the
notification about your fix).
Have a nice week,
Carsten
> -----Ursprungliche Nachricht-----
> Von: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 13. Juli 2001 10:22
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: [Xalan-J 2.2.0D6]: Strange problems with DOM and XPath
>
>
> 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(SuballocatedI
> ntVector.j
> > ava:440)
> > at
> org.apache.xml.dtm.ref.DTMDefaultBase._exptype(DTMDefaultBase.java:485)
> > at
> >
> org.apache.xml.dtm.ref.DTMDefaultBase.getExpandedTypeID(DTMDefault
> Base.java:
> > 1362)
> > at
> >
> org.apache.xml.dtm.ref.DTMDefaultBase.declareNamespaceInContext(DT
> MDefaultBa
> > 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.nex
> t(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
