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 | 10 months ago
tip
Do you know that we can give you better hits? Get more relevant results from Samebug’s stack trace search.
  1. 0

    Saxon XSLT and XQuery Processor / Mailing Lists

    sourceforge.net | 10 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

    开源中国(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(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