Hello,
with the serialized dom/node attached to the last mail it is possible to
reproduce the exception by simply calling XPathAPI.selectNodeList(node,
"*/*");
After some investigation into the code of the SuballocatedIntVector
we found out that placing a try/catch block around the method which
catches the NullPointerException and returns 0 in that case, solves
the problem!
>>>>
public int elementAt(int i)
{
// %OPT% Does this really buy us anything? Test versus division for
small,
// test _plus_ division for big docs.
if(i<m_blocksize)
return m_map0[i];
try {
return m_map[i/m_blocksize][i%m_blocksize];
} catch (NullPointerException npe) {
return 0;
}
}
<<<<<<
The bug here seems to be that the object calling the elementAt() method
does not handle correctly the NPE. There are other places throughout
Xalan where this method is called, a NPE is thrown and that is handled
properly (= catched by the calling object).
The comment for this method states the circumstances for the exception
and suggests to further investigate here. But perhaps adding the above
try/catch is enough.
I hope this helps in finding the problem.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: [EMAIL PROTECTED]
================================================================
>
> 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.
> > > > > > >
>
