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)

Solutions on the web28683

  • via sourceforge.net by Unknown author, 1 year ago
    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
  • via nabble.com by Unknown author, 1 year ago
    >>>> >> > > > i have ejbs,entities,classes etc, but now i need to separate my >>>> >> EJB's, >>>> >> > > and >>>> >> > > > then i am trying to use ear file for this, but honestly i am >>>> not sure >>>> >> > if >>>> >> > > > this is correct
  • Already tesselating!" I don't know what tesselating means but when I dug deeper into the crash report I saw something related to BuildCraft: "at net.minecraft.client.renderer.Tessellator.func_78371_b(Tessellator.java:374)
  • Stack trace

    • 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) at test.ZinovievTest.readFromXML(ZinovievTest.java:172) at test.ZinovievTest.main(ZinovievTest.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    Write tip

    You have a different solution? A short tip here would help you and many other users who saw this issue last week.

    Users with the same issue

    You are the first who have seen this exception. Write a tip to help other users and build your expert profile.