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)

sourceforge.net | 9 months ago
tip
Your exception is missing from the Samebug knowledge base.
Here are the best solutions we found on the Internet.
Click on the to mark the helpful solution and get rewards for you help.
  1. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 9 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)
  2. 0

    开源中国(OSChina.NET)

    oschina.net | 2 years ago
    java.lang.IllegalStateException: Tomcat connector in failed state at org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServle tContainer.start(TomcatEmbeddedServletContainer.java:157) at org.springframework.boot.context.embedded.EmbeddedWebApplicationConte xt.startEmbeddedServletContainer(EmbeddedWebApplicationContext.java:288) at org.springframework.boot.context.embedded.EmbeddedWebApplicationConte xt.finishRefresh(EmbeddedWebApplicationContext.java:141) at org.springframework.context.support.AbstractApplicationContext.refres h(AbstractApplicationContext.java:483) at org.springframework.boot.context.embedded.EmbeddedWebApplicationConte xt.refresh(EmbeddedWebApplicationContext.java:118) at org.springframework.boot.SpringApplication.refresh(SpringApplication. java:686) at org.springframework.boot.SpringApplication.run(SpringApplication.java :320) at org.springframework.boot.SpringApplication.run(SpringApplication.java :957) at org.springframework.boot.SpringApplication.run(SpringApplication.java :946) at com.baidu.rigel.biplatform.tesseract.application.TesseractApplication .main(TesseractApplication.java:63)
  3. 0

    Error while parsing common domain names using InternetDomainName.java

    GitHub | 2 years ago | marios-caspida
    java.lang.IllegalStateException: Not under a public suffix: us-east-1.amazonaws.com > at com.google.common.base.Preconditions.checkState(Preconditions.java:197) > at com.google.common.net.InternetDomainName.topPrivateDomain(InternetDomainName.java:424) > at *****.main(MyTestJavaClass.java:8> 9)
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Sonar runner is failing - Error while creating file [90062-167]

    Stack Overflow | 4 years ago | Biscuit128
    java.lang.IllegalStateException: Fail to connect to database at org.sonar.core.persistence.DefaultDatabase.start(DefaultDatabase.java :72)
  6. 0

    Does Spring actually start a new transaction with REQUIRES_NEW?

    Stack Overflow | 3 years ago | Johan
    java.lang.IllegalStateException: <strong>Trying to change transaction TransactionImple &lt; ac, BasicAction: 0:ffff7f000101:126a:542d2010:d8 status: ActionStatus.RUNNING > in enlist!</strong> at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:690) at org.jboss.resource.connectionmanager.TxConnectionManager.transactionStarted(TxConnectionManager.java:427) at org.jboss.resource.connectionmanager.CachedConnectionManager.userTransactionStarted(CachedConnectionManager.java:350) at org.jboss.tm.usertx.UserTransactionRegistry.userTransactionStarted(UserTransactionRegistry.java:119) at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:141) at org.springframework.transaction.jta.JtaTransactionManager.doJtaBegin(JtaTransactionManager.java:875) at org.springframework.transaction.jta.JtaTransactionManager.doBegin(JtaTransactionManager.java:832) at org.springframework.transaction.support.AbstractPlatformTransactionManager.handleExistingTransaction(AbstractPlatformTransactionManager.java:425) at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:349) at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:438) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:261) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) at com.sun.proxy.$Proxy234.request(Unknown Source) at com.izazi.ioriginate.framework.spring.jms.AbstractRequestReply.request(AbstractRequestReply.java:58) at com.izazi.ioriginate.service.addressvalidation.AddressValidationServiceImpl.validate(AddressValidationServiceImpl.java:34)

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