java.lang.IllegalStateException: Cannot call next() when input is exhausted

sourceforge.net | 4 months ago
  1. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 4 months ago
    java.lang.IllegalStateException: Cannot call next() when input is exhausted
  2. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 4 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(PullNamespaceReducer.java:71) >> at net.sf.saxon.pull.PullToStax.next(PullToStax.java:223) >> at >> com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:156) >> at >> com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:333) >> at >> com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.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)
  3. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 4 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)
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 4 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(PullNamespaceReducer.java:71) > at net.sf.saxon.pull.PullToStax.next(PullToStax.java:223) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:156) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:333) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.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)
  6. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 4 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)

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.lang.IllegalStateException

      Cannot call next() when input is exhausted

      at net.sf.saxon.tinytree.TinyTreeWalker.next()
    2. Saxon
      TinyTreeWalker.next
      1. net.sf.saxon.tinytree.TinyTreeWalker.next(TinyTreeWalker.java:196)
      1 frame
    3. Saxon HE
      PullToStax.next
      1. net.sf.saxon.pull.PullFilter.next(PullFilter.java:85)
      2. net.sf.saxon.pull.PullNamespaceReducer.next(PullNamespaceReducer.java:71)
      3. net.sf.saxon.pull.PullToStax.next(PullToStax.java:223)
      3 frames
    4. Java RT
      UnmarshallerImpl.unmarshal
      1. com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:156)
      2. com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:333)
      3. com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:312)
      3 frames
    5. Unknown
      TaskImpl.main
      1. TaskImpl.readFromXML(TaskImpl.java:182)
      2. TaskImpl.main(TaskImpl.java:336)
      2 frames