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 | 6 months ago
  1. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 6 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)
  2. 0
    Update to Grails 3.0.x
  3. 0
    The application is unable to connect to the database. It could be resolved by configuring access privileges on the database side.
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0
    Execute mvn dependency:tree from your project's root directory.
  6. 0
    You should define the TestContext class in your classpath

    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(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