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

    4K(2160 resolution) video is not playing

    GitHub | 1 year ago | pprateek786
    java.lang.IllegalStateException: No variants selected. at com.test.media.player.support.exoplayer.HlsRendererBuilder$AsyncRendererBuilder.onSingleManifest(HlsRendererBuilder.java:146) at com.test.media.player.support.exoplayer.HlsRendererBuilder$AsyncRendererBuilder.onSingleManifest(HlsRendererBuilder.java:85)
  3. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 4 months ago
    java.lang.IllegalStateException: Cannot call next() when input is exhausted
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Re: FATAL Unable to register shutdown hook because JVM is shutting down.

    apache.org | 1 year ago
    java.lang.IllegalStateException: Cannot add new >> shutdown hook as this is not started. Current state: STOPPED at >> org.apache.logging.log4j.core.util.DefaultShutdownCallbackRegistry.addShutdownCallback(DefaultShutdownCallbackRegistry.java:113) at >> org.apache.logging.log4j.core.impl.Log4jContextFactory.addShutdownCallback(Log4jContextFactory.java:244) at >> org.apache.logging.log4j.core.LoggerContext.setUpShutdownHook(LoggerContext.java:182) at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:143) at >> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:146) at >> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:41) at org.apache.logging.log4j.LogManager.getContext(LogManager.java:175) at >> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:102) at >> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43) at >> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:42) at >> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
  6. 0

    java.lang.IllegalStateException: Cannot create a session after the response has been committed - Toolbox for IT Groups

    ittoolbox.com | 7 months ago
    java.lang.IllegalStateException: Cannot create a session after the response has been committed at org.apache.coyote.tomcat5.CoyoteRequest.doGetS ession(CoyoteRequest.java: 2456) at org.apache.coyote.tomcat5.CoyoteRequest.getSes sion(CoyoteRequest.java:22 91) at org.apache.coyote.tomcat5.CoyoteRequestFacade. getSession(CoyoteRequestFa cade.java:838) at javax.servlet.http.HttpServletRequestWrapper.g etSession(HttpServletReque stWrapper.java:265) at org.apache.catalina.core.ApplicationHttpReques t.getSession(ApplicationHt tpRequest.java:557) at javax.servlet.http.HttpServletRequestWrapper.g etSession(HttpServletReque stWrapper.java:265) at org.apache.catalina.core.ApplicationHttpReques t.getSession(ApplicationHt tpRequest.java:557) at org.apache.catalina.core.ApplicationHttpReques t.getSession(ApplicationHt tpRequest.java:501) at org.apache.jasper.runtime.PageContextImpl._ini tialize(PageContextImpl.ja va:152) at org.apache.jasper.runtime.PageContextImpl.init ialize(PageContextImpl.jav a:127) at org.apache.jasper.runtime.JspFactoryImpl.inter nalGetPageContext(JspFacto ryImpl.java:109) at org.apache.jasper.runtime.JspFactoryImpl.acces s$000(JspFactoryImpl.java: 42) at org.apache.jasper.runtime.JspFactoryImpl$Privi legedGetPageContext.run(Js pFactoryImpl.java:156) at java.security.AccessController.doPrivileged(Native Method) at org.apache.jasper.runtime.JspFactoryImpl.getPa geContext(JspFactoryImpl.j ava:64) at org.apache.jsp.jsp.rpt.svc_005fusage_005fdetai l_005frpt_jsp._jspService( svc_005fusage_005fdetail_005frpt_jsp.java:117) at org.apache.jasper.runtime.HttpJspBase.service(Http JspBase.java:105) at javax.servlet.http.HttpServlet.service(HttpServlet .java:860) at org.apache.jasper.servlet.JspServletWrapper.se rvice(JspServletWrapper.ja va:336) at org.apache.jasper.servlet.JspServlet.serviceJs pFile(JspServlet.java:302) at org.apache.jasper.servlet.JspServlet.service(JspSe rvlet.java:251) at javax.servlet.http.HttpServlet.service(HttpServlet .java:860) at sun.reflect.GeneratedMethodAccessor187.invoke(Unkn own Source) at sun.reflect.DelegatingMethodAccessorImpl.invok e(DelegatingMethodAccessor Impl.java:25)

    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