java.lang.IllegalStateException: Cannot > > call > > next() when input is exhausted > > at > net.sf.saxon.tinytree.TinyTreeWalker.next(TinyTreeWalker.java:196) > > at net.sf.saxon.pull.PullFilter.next(PullFilter.java:85) > > at > > > net.sf.saxon.pull.PullNamespaceReducer.next(PullNamespaceReduc > er.java:71) > > at net.sf.saxon.pull.PullToStax.next(PullToStax.java:223) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamCo > nnector.bridge(StAXStreamConnector.java:156) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.Unmarshaller > Impl.unmarshal0(UnmarshallerImpl.java:333) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.Unmarshaller > Impl.unmarshal(UnmarshallerImpl.java:312) > > at TaskImpl.readFromXML(TaskImpl.java:182) > > at TaskImpl.main(TaskImpl.java:336) > > > > I wonder whether these two variants are equivalent > > > > > > Nikita Zinoviev wrote: > > > >> Good luck to you, this seems rather eye-catching! > >> I don't know much about JAXB, though I explored some > openjdk sources > >> for UnmarshallerImpl via google codesearch. > >> > >> Nikita > >> > >> Michael Kay wrote: > >> > >> > >>> Just another progress report on this: can't entirely blame the > >>> Unmarshaller for falling over, because it seems the > stream of events > >>> delivered by Saxon isn't actually well-balanced. This could be a > >>> consequence of a bad patch for another problem. Will need > to investigate further. > >>> > >>> Michael Kay > >>> > >>> > >>> > >>> > >>> -----Original Message----- From: Michael Kay [mailto:mike@...] Sent: 30 March 2009 23:14 To: 'Mailing list for the SAXON XSLT and XQuery processor' Subject: Re: [saxon] Forwarding saxon results to JAXB > unmarshaller via S9API > Shouldn't be hard to fix. > > > Perhaps I spoke too soon. After Saxon returns the END_DOCUMENT event, the > Unmarshaller calls next() again. It shouldn't do this; the only valid call in END_DOCUMENT state is close(). So Saxon should either throw NoSuchElementException ("if next() is called when hasNext() returns false"), or IllegalStateException ("If > a method is called in an invalid state the method will throw a java.lang.IllegalStateException"). But either exception simply causes the Unmarshaller to bomb out with a stack trace. So I don't really know what's going on: I don't think the Unmarshaller is behaving in a conformant way. Here's the > stack trace: Exception in thread "main" java.lang.IllegalStateException at net.sf.saxon.evpull.EventToStaxBridge.nextx(EventToStaxBridge. java:257) at > net.sf.saxon.evpull.EventToStaxBridge.next(EventToStaxBridge.java:233) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.b ridge(StAXStre amConnector.java:126) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unma rshal0(Unmarsh allerImpl.java:333) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unma rshal(Unmarsha llerImpl.java:312)

sourceforge.net | 7 months ago
tip
Do you know that we can give you better hits? Get more relevant results from Samebug’s stack trace search.
  1. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 7 months ago
    java.lang.IllegalStateException: Cannot > > call > > next() when input is exhausted > > at > net.sf.saxon.tinytree.TinyTreeWalker.next(TinyTreeWalker.java:196) > > at net.sf.saxon.pull.PullFilter.next(PullFilter.java:85) > > at > > > net.sf.saxon.pull.PullNamespaceReducer.next(PullNamespaceReduc > er.java:71) > > at net.sf.saxon.pull.PullToStax.next(PullToStax.java:223) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamCo > nnector.bridge(StAXStreamConnector.java:156) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.Unmarshaller > Impl.unmarshal0(UnmarshallerImpl.java:333) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.Unmarshaller > Impl.unmarshal(UnmarshallerImpl.java:312) > > at TaskImpl.readFromXML(TaskImpl.java:182) > > at TaskImpl.main(TaskImpl.java:336) > > > > I wonder whether these two variants are equivalent > > > > > > Nikita Zinoviev wrote: > > > >> Good luck to you, this seems rather eye-catching! > >> I don't know much about JAXB, though I explored some > openjdk sources > >> for UnmarshallerImpl via google codesearch. > >> > >> Nikita > >> > >> Michael Kay wrote: > >> > >> > >>> Just another progress report on this: can't entirely blame the > >>> Unmarshaller for falling over, because it seems the > stream of events > >>> delivered by Saxon isn't actually well-balanced. This could be a > >>> consequence of a bad patch for another problem. Will need > to investigate further. > >>> > >>> Michael Kay > >>> > >>> > >>> > >>> > >>> -----Original Message----- From: Michael Kay [mailto:mike@...] Sent: 30 March 2009 23:14 To: 'Mailing list for the SAXON XSLT and XQuery processor' Subject: Re: [saxon] Forwarding saxon results to JAXB > unmarshaller via S9API > Shouldn't be hard to fix. > > > Perhaps I spoke too soon. After Saxon returns the END_DOCUMENT event, the > Unmarshaller calls next() again. It shouldn't do this; the only valid call in END_DOCUMENT state is close(). So Saxon should either throw NoSuchElementException ("if next() is called when hasNext() returns false"), or IllegalStateException ("If > a method is called in an invalid state the method will throw a java.lang.IllegalStateException"). But either exception simply causes the Unmarshaller to bomb out with a stack trace. So I don't really know what's going on: I don't think the Unmarshaller is behaving in a conformant way. Here's the > stack trace: Exception in thread "main" java.lang.IllegalStateException at net.sf.saxon.evpull.EventToStaxBridge.nextx(EventToStaxBridge. java:257) at > net.sf.saxon.evpull.EventToStaxBridge.next(EventToStaxBridge.java:233) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.b ridge(StAXStre amConnector.java:126) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unma rshal0(Unmarsh allerImpl.java:333) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unma rshal(Unmarsha llerImpl.java:312)

    Root Cause Analysis

    1. java.lang.IllegalStateException

      Cannot > > call > > next() when input is exhausted > > at > net.sf.saxon.tinytree.TinyTreeWalker.next(TinyTreeWalker.java:196) > > at net.sf.saxon.pull.PullFilter.next(PullFilter.java:85) > > at > > > net.sf.saxon.pull.PullNamespaceReducer.next(PullNamespaceReduc > er.java:71) > > at net.sf.saxon.pull.PullToStax.next(PullToStax.java:223) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamCo > nnector.bridge(StAXStreamConnector.java:156) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.Unmarshaller > Impl.unmarshal0(UnmarshallerImpl.java:333) > > at > > > com.sun.xml.internal.bind.v2.runtime.unmarshaller.Unmarshaller > Impl.unmarshal(UnmarshallerImpl.java:312) > > at TaskImpl.readFromXML(TaskImpl.java:182) > > at TaskImpl.main(TaskImpl.java:336) > > > > I wonder whether these two variants are equivalent > > > > > > Nikita Zinoviev wrote: > > > >> Good luck to you, this seems rather eye-catching! > >> I don't know much about JAXB, though I explored some > openjdk sources > >> for UnmarshallerImpl via google codesearch. > >> > >> Nikita > >> > >> Michael Kay wrote: > >> > >> > >>> Just another progress report on this: can't entirely blame the > >>> Unmarshaller for falling over, because it seems the > stream of events > >>> delivered by Saxon isn't actually well-balanced. This could be a > >>> consequence of a bad patch for another problem. Will need > to investigate further. > >>> > >>> Michael Kay > >>> > >>> > >>> > >>> > >>> -----Original Message----- From: Michael Kay [mailto:mike@...] Sent: 30 March 2009 23:14 To: 'Mailing list for the SAXON XSLT and XQuery processor' Subject: Re: [saxon] Forwarding saxon results to JAXB > unmarshaller via S9API > Shouldn't be hard to fix. > > > Perhaps I spoke too soon. After Saxon returns the END_DOCUMENT event, the > Unmarshaller calls next() again. It shouldn't do this; the only valid call in END_DOCUMENT state is close(). So Saxon should either throw NoSuchElementException ("if next() is called when hasNext() returns false"), or IllegalStateException ("If > a method is called in an invalid state the method will throw a java.lang.IllegalStateException"). But either exception simply causes the Unmarshaller to bomb out with a stack trace. So I don't really know what's going on: I don't think the Unmarshaller is behaving in a conformant way. Here's the > stack trace: Exception in thread "main" java.lang.IllegalStateException at net.sf.saxon.evpull.EventToStaxBridge.nextx(EventToStaxBridge. java:257) at > net.sf.saxon.evpull.EventToStaxBridge.next(EventToStaxBridge.java:233) at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.b ridge(StAXStre amConnector.java:126) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unma rshal0(Unmarsh allerImpl.java:333) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unma rshal(Unmarsha llerImpl.java:312)

      at test.ZinovievTest.readFromXML()
    2. test
      ZinovievTest.main
      1. test.ZinovievTest.readFromXML(ZinovievTest.java:172)
      2. test.ZinovievTest.main(ZinovievTest.java:301)
      2 frames
    3. Java RT
      NativeMethodAccessorImpl.invoke0
      1. sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      1 frame