Is Jersey 1.8 compatible with Java 8?
Also, is Jersey 1.8 compatible with WildFly 8 on Java 8?
I developed and I am now maintaining a REST
web service project which produces a WAR.
We started having some problems with this like 6 months ago
(but btw we only now noticed them). See error and screenshot below.
After doing quite some research on the web,
it seems to me the problems are related to the fact that our project
was migrated to Java 8 and WildFly 8 (previously it was running on Tomcat
6 with Java 6).
So... I thought the solution is to migrate to at least Jersey 1.9
(we don't want to use the Jersey 2.x line).
I tried it but I am getting the same error.
So... is Jersey 1.x at all compatible with WildFly 8 and Java 8?
The error which we started getting looks like this.
07:27:33,894 INFO [com.sun.jersey.api.core.WebAppResourceConfig] (default task-7) Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes
07:27:36,984 ERROR [io.undertow.request] (default task-7) UT005023: Exception handling request to /rpt/rpt-rest-service/report: java.lang.ArrayIndexOutOfBoundsException: 1901
at org.objectweb.asm.ClassReader.readClass(Unknown Source) [asm-3.1.jar:3.1]
at org.objectweb.asm.ClassReader.accept(Unknown Source) [asm-3.1.jar:3.1]
at org.objectweb.asm.ClassReader.accept(Unknown Source) [asm-3.1.jar:3.1]
at com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:133) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.core.spi.scanning.JarFileScanner.scan(JarFileScanner.java:97) [jersey-core-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.scanning.WebAppResourcesScanner$1.f(WebAppResourcesScanner.java:94) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.core.util.Closing.f(Closing.java:71) [jersey-core-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.scanning.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:92) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.scanning.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:79) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.WebAppResourceConfig.init(WebAppResourceConfig.java:100) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.WebAppResourceConfig.<init>(WebAppResourceConfig.java:87) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.api.core.WebAppResourceConfig.<init>(WebAppResourceConfig.java:72) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.WebComponent.getWebAppResourceConfig(WebComponent.java:672) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:414) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:581) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.WebServletConfig.getDefaultResourceConfig(WebServletConfig.java:87) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:703) [jersey-server-1.8-SNAPSHOT.jar:1.8-SNAPSHOT]
.......
The same exception I get in the browser when calling my REST web service.
Note that there have been no code or library or config changes in this project
(which produces that WAR). I believe only the deployment environment was changed.
As it usually happens an hour or two after asking here, I found the solution.
The solution is to upgrade Jersey from 1.8 to some later version from the 1.x Jersey line.
First I tried a minimalistic approach and upgraded to version 1.9 but that one had the same issue.
So then I just upgraded to the latest version from the 1.x Jersey line (which is version 1.19.3 as of this moment). This solved the problem.
Related
I have JAX-RS based REST API running on WebSphere Application Server Version 8.5.5.9 Liberty Profile. It got below dependencies. Webservices worked fine.
Due to some security vulneribilites in Jackson Library I updated to 2.11 version. Now my dependencies look like this:
Now When I start my server or make API call I see the below error message in log:
[6/8/20 16:47:14:929 CDT] 0000004d id= com.ibm.ws.webcontainer.servlet.ServletWrapper E init SRVE0271E: Uncaught init() exception created by servlet [REST Service] in application [webservices]: java.lang.IllegalArgumentException
at jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:170)
at jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:153)
at jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:424)
at com.sun.jersey.spi.scanning.AnnotationScannerListener.onProcess(AnnotationScannerListener.java:138)
at com.sun.jersey.core.spi.scanning.JarFileScanner.scan(JarFileScanner.java:97)
at com.sun.jersey.spi.scanning.servlet.WebAppResourcesScanner$1.f(WebAppResourcesScanner.java:94)
at com.sun.jersey.core.util.Closing.f(Closing.java:71)
at com.sun.jersey.spi.scanning.servlet.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:92)
at com.sun.jersey.spi.scanning.servlet.WebAppResourcesScanner.scan(WebAppResourcesScanner.java:79)
at com.sun.jersey.api.core.ScanningResourceConfig.init(ScanningResourceConfig.java:80)
at com.sun.jersey.api.core.servlet.WebAppResourceConfig.init(WebAppResourceConfig.java:102)
at com.sun.jersey.api.core.servlet.WebAppResourceConfig.<init>(WebAppResourceConfig.java:89)
at com.sun.jersey.api.core.servlet.WebAppResourceConfig.<init>(WebAppResourceConfig.java:74)
at com.sun.jersey.spi.container.servlet.WebComponent.getWebAppResourceConfig(WebComponent.java:668)
at com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:435)
at com.sun.jersey.spi.container.servlet.ServletContainer.getDefaultResourceConfig(ServletContainer.java:602)
at com.sun.jersey.spi.container.servlet.WebServletConfig.getDefaultResourceConfig(WebServletConfig.java:87)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:699)
at com.sun.jersey.spi.container.servlet.WebComponent.createResourceConfig(WebComponent.java:674)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:205)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:394)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:577)
at javax.servlet.GenericServlet.init(GenericServlet.java:161)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:332)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:633)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:475)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1161)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:4869)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.handleRequest(DynamicVirtualHost.java:297)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:997)
at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:262)
at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:955)
at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:341)
at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:471)
at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:405)
at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:285)
at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:256)
at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:174)
at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:83)
at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:929)
at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1018)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.lang.Thread.run(Thread.java:820)
Only code change I made is replacing
import org.codehaus.jackson.map.ObjectMapper;
with
import com.fasterxml.jackson.databind.ObjectMapper;
Any thoughts on how to resolve this.
I am wondering if I have to update Jersey.
org.codehaus.jackson is an older version of Jackson.
com.fasterxml.jackson represents the new project and package.
Your server is using new version of ObjectMapper so if it do not work, consider to upgrade Jersey also
https://mvnrepository.com/artifact/org.glassfish.jersey.core/jersey-client
https://mvnrepository.com/artifact/org.glassfish.jersey.core/jersey-server
Tell me at comment if you have any issue ^^
I am getting this exception during tomcat start. I am using jdk1.8.0_152, apache-tomcat-8.5.24
I have been updating my elasticsearch from version 1.7 to 6.0. For that I had to include few new jars and had to update few existing to latest versions.(commons-io-2.6,lucene-core-7.0.1,log4j-api-2.9.1) After that I am getting this error on tomcat starting.
SEVERE [localhost-startStop-1]
org.apache.catalina.core.ApplicationContext.log
StandardWrapper.Throwable java.lang.ArrayIndexOutOfBoundsException:
41981 at org.objectweb.asm.ClassReader.(Unknown Source) at
org.objectweb.asm.ClassReader.(Unknown Source) at
org.objectweb.asm.ClassReader.(Unknown Source)
What version of asm do you use? According to this post https://github.com/joaoarthurbm/designwizard/issues/36:
asm-3.1 doesn't support lambdas expression available in JDK 8.
So you might be want to upgrade to asm 5.0.1 or higher.
I have to use Karaf 3.0.1 to run some legacy code that requires some changes. I don't often use Karaf directly, but I usually use a much more recent version.
I installed Karaf 3.0.1 from the archive site, set a couple of properties (KARAF_OPTS to set a proxy, and JAVA_MAX_MEM) and then started Karaf.
The first thing I need to run (according to a setup process written by someone else) is a config:property-append command.
When I do this, it just prints Error executing command: java.lang.NullPointerException, with no other information.
I even get this with just config:property-append --help, so it's not an issue with the parameters I'm giving it.
What might be wrong here, and what can I do to get more information?
Update:
It did occur to me now to check in the Karaf distribution for a log file, and I did find the NPE there, so I'm including that stack trace, and a stack trace that comes before it.
java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.apache.aries.proxy.impl.gen.ProxySubclassAdapter.visit(ProxySubclassAdapter.java:274)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.processClass(ProxySubclassGenerator.java:245)
at org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.generateAndLoadSubclass(ProxySubclassGenerator.java:224)
at org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.getProxySubclass(ProxySubclassGenerator.java:126)
at org.apache.aries.proxy.impl.gen.ProxySubclassGenerator.newProxySubclassInstance(ProxySubclassGenerator.java:161)
at org.apache.aries.proxy.impl.AsmProxyManager.createNewProxy(AsmProxyManager.java:103)
at org.apache.aries.proxy.impl.AbstractProxyManager.createDelegatingInterceptingProxy(AbstractProxyManager.java:75)
at org.apache.aries.proxy.impl.AbstractProxyManager.createInterceptingProxy(AbstractProxyManager.java:53)
at org.apache.aries.blueprint.container.ServiceRecipe$TriggerServiceFactory.getService(ServiceRecipe.java:535)
at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
at org.apache.felix.framework.Felix.getService(Felix.java:3568)
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)
at org.apache.karaf.service.guard.impl.GuardProxyCatalog$ProxyServiceFactory.getService(GuardProxyCatalog.java:424)
at org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:308)
at org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:219)
at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:320)
at org.apache.felix.framework.Felix.getService(Felix.java:3568)
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:468)
at org.apache.karaf.shell.console.completer.CommandsCompleter.unProxy(CommandsCompleter.java:298)
at org.apache.karaf.shell.console.completer.CommandsCompleter.checkData(CommandsCompleter.java:234)
at org.apache.karaf.shell.console.completer.CommandsCompleter.complete(CommandsCompleter.java:86)
at org.apache.karaf.shell.console.impl.jline.CompleterAsCompletor.complete(CompleterAsCompletor.java:32)
at jline.console.ConsoleReader.complete(ConsoleReader.java:3077)[26:jline:2.11.0]
at jline.console.ConsoleReader.readLine(ConsoleReader.java:2501)[26:jline:2.11.0]
at jline.console.ConsoleReader.readLine(ConsoleReader.java:2162)[26:jline:2.11.0]
at org.apache.karaf.shell.console.impl.jline.ConsoleImpl.readAndParseCommand(ConsoleImpl.java:280)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.java:207)[37:org.apache.karaf.shell.console:3.0.1]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_102]
at org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3.doRun(ConsoleFactoryService.java:126)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3$1.run(ConsoleFactoryService.java:117)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_102]
at org.apache.karaf.jaas.modules.JaasHelper.doAs(JaasHelper.java:47)[38:org.apache.karaf.jaas.modules:3.0.1]
at org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3.run(ConsoleFactoryService.java:115)[37:org.apache.karaf.shell.console:3.0.1]
2017-09-27 15:41:18,970 | ERROR | Local user karaf | ShellUtil | 37 - org.apache.karaf.shell.console - 3.0.1 | Exception caught while executing command
java.lang.NullPointerException
at org.apache.felix.gogo.runtime.Reflective.invoke(Reflective.java:61)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.karaf.shell.console.impl.jline.ConsoleImpl$DelegateSession.execute(ConsoleImpl.java:521)
at org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.java:212)
at java.lang.Thread.run(Thread.java:745)[:1.8.0_102]
at org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3.doRun(ConsoleFactoryService.java:126)[37:org.apache.karaf.shell.console:3.0.1]
at org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3$1.run(ConsoleFactoryService.java:117)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_102]
at org.apache.karaf.jaas.modules.JaasHelper.doAs(JaasHelper.java:47)[38:org.apache.karaf.jaas.modules:3.0.1]
at org.apache.karaf.shell.console.impl.jline.ConsoleFactoryService$3.run(ConsoleFactoryService.java:115)[37:org.apache.karaf.shell.console:3.0.1]
As you can see, an IllegalArgumentException comes before the NPE. I don't know whether they are related.
Note that I'm running this with Java 8.
Does Karaf 3.0.1 not run with Java 8?
I asked about this on the Karaf user list, and one person said they've had no trouble running Karaf 3.x with Java 8.
Update:
Despite the fact that a knowledgeable person said Karaf 3.x (they tested 3.0.7) works fine with Java 8, I found that after I changed my Karaf to use 1.7.0_131, my problem went away. So I guess that's my answer.
Following is the timeline of how i got error in my application
Used Spring 2.5.3 and tomcat 7.0.27 - No Error
Upgraded to Spring 3.1.1 with same tomcat (7.0.27) - No Error
Upgraded tomcat to 7.0.42, used with Spring 3.1.1 - VerifyError
When i stop my application, i get 1000 verifyerrors (seperate error for every destroyBean) when i upgraded to tomcat 7.0.42.
Following is the Stack Trace:
java.lang.VerifyError: (class: org/springframework/orm/jpa/EntityManagerFactoryUtils, method: convertJpaAccessExceptionIfPossible signature: (Ljava/lang/RuntimeException;)Lorg/springframework/dao/DataAccessException;) Wrong return type in function
at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessBeforeDestruction(PersistenceAnnotationBeanPostProcessor.java:357)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:193)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:498)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:509)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:474)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:442)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1066)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1040)
at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:988)
at org.springframework.web.context.ContextLoader.closeWebApplicationContext(ContextLoader.java:556)
at org.springframework.web.context.ContextLoaderListener.contextDestroyed(ContextLoaderListener.java:142)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:4980)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5626)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Possible Cause:
fixed EntityManagerFactoryUtils's "convertJpaAccessException" to always return rather than throw DataAccessExceptions
This line is in ChangeLog of Spring 2.5.6
But my application works fine with Spring 3.1.1 and tomcat 7.0.27 but throws this error when upgraded to tomcat 7.0.42
AFAIK, Tomcat doesn't depend on Spring, and Spring doesn't depend on Tomcat. Not in any version of either.
I suspect that in the intermediate version of your application after "upgrade to Spring 3.1.1 with same tomcat (7.0.27)", you either didn't trigger that code to be run. Note that it is happening in code that is run when a webapp is shut. If you never attempted a clean shutdown in the intermediate version of your application, that postProcessBeanBeforeDestruction method wouldn't be called on that bean, and the problem wouldn't arise.
My guess is that the real problem is caused by mixing versions of Spring JAR files.
Having a problem running AMTU on a windows 7 Pro Machine.
It runs fine when it opens but it crashes after running a few days.
Here is the Crash Report.
2013-09-14 09:48:19,482 [pool-3-thread-3] com.amazon.merchants.services.RetrieverService - Unable to retrieve unacknowledged report information - MWS Request ID unknown
2013-09-14 09:48:19,482 [pool-3-thread-3] com.amazon.merchants.services.RetrieverService - MWS responded with an error: Internal Error
com.amazonaws.mws.MarketplaceWebServiceException: Internal Error
at com.amazonaws.mws.MarketplaceWebServiceClient.processErrors(MarketplaceWebServiceClient.java:2342)
at com.amazonaws.mws.MarketplaceWebServiceClient.invoke(MarketplaceWebServiceClient.java:2231)
at com.amazonaws.mws.MarketplaceWebServiceClient.invoke(MarketplaceWebServiceClient.java:2011)
at com.amazonaws.mws.MarketplaceWebServiceClient.getReportList(MarketplaceWebServiceClient.java:1206)
at com.amazon.merchants.services.RetrieverService.processReportCheck(RetrieverService.java:94)
at com.amazon.merchants.services.RetrieverService.run(RetrieverService.java:46)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I also cannot start the Windows Service called AMTU. Get the following Error:
The AMTU service on local computer has started and then stopped
I am suspecting its a Java version issue.
In the AMTU documentation it says "requires Java version 1.6.0 or later (listed as JDK/JRE - 6)" and links to http://www.oracle.com/technetwork/java/archive-139210.html. The link has many download links, but nothing listed "JDK/JRE - 6".
AMTU documentation: https://d28hcfptedr5ia.cloudfront.net/ug/AMTU_2.2_UserGuide.pdf
Any Ideas?
Thanks in advance.
The way I read this crash report, AMTU got an unexpected result from the MWS servers:
MWS responded with an error: Internal Error
It seems the error handling in AMTU is not good enough to gracefully handle a HTTP status 500, and there is not a lot you can do about this. You could put a HTTP proxy in between and catch a HTTP 500 on the line before it gets to the AMTU, replacing it with something that AMTU handles more gracefully (e.g. an empty XML result or a time out). It would be preferrable though that Amazon doesn't send those errors back, after all, a 500 is an error on their side of things.
I seriously doubt the Java version has anything to do with this, but just in case: You can still download JRE6 even though it is end-of-life:
Java 6 downloads
Please note that the true name of JRE6 is "Java SE runtime environment" and JDK6 is called "Java SE development kit". At the time of writing, the most current version is "update 45". You may need to uninstall Java 7 to make sure the AMTU actually uses the version you want it to. Please also note that since AMTU is a 32bit process, you will need the 32bit JRE even if it is run on a 64bit windows.