Packaging a hello world application generated by the wildfly swarm generator and built with Java9 crashes when deploying the application.
It seems that the reason is the swarm/undertow dependency to the org.ow2.asm:asm-all:5.0.4 which is not Java9 ready.
Is there a known workaround, or a known date when swarm will be ready for Java9?
The stacktrace is:
Caused by: 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.wildfly.swarm.jaxrs.internal.JAXRSArchiveImpl.isJAXRS(JAXRSArchiveImpl.java:117)
at org.wildfly.swarm.jaxrs.internal.JAXRSArchiveImpl.isJAXRS(JAXRSArchiveImpl.java:96)
at org.wildfly.swarm.jaxrs.JAXRSArchive.isJAXRS(JAXRSArchive.java:55)
at org.wildfly.swarm.jaxrs.internal.DefaultJAXRSWarDeploymentFactory.create(DefaultJAXRSWarDeploymentFactory.java:46)
at org.wildfly.swarm.jaxrs.internal.DefaultJAXRSWarDeploymentFactory$Proxy$_$$_WeldClientProxy.create(Unknown Source)
org.wildfly.swarm.container.runtime.deployments.DefaultDeploymentCreator.createDefaultDeployment(DefaultDeploymentCreator.java:69)
The class files in JDK 9 are v53.0 so you need ASM 6. ASM has always thrown IAE when encountering class files that are newer that it supports.
The IllegalArgumentException can be possibly caused by different class version when scanning the bytecode which in your case which is done by org.ow2.asm:asm-all:5.0.4.
We faced similar issue faced in jetty.project#1758 which I'd to try and solve by building the jetty.project by myself but to eventually realize that org.ow2.asm would chain me back still.
The latest available version of asm on maven is :
<dependency>
<groupId>org.ow2.asm</groupId>
<artifactId>asm-all</artifactId>
<version>6.0_BETA</version>
</dependency>
In case of jetty (and probably swarm as well) they were not able to integrate this as 6.0_BETA is not a valid OSGI version number:
Caused by: java.lang.IllegalArgumentException: invalid range
"[6.0_BETA,6.0_BETA]": invalid version "6.0_BETA": non-numeric
"0_BETA"
Related to the above a read to how jetty tried solving it.
There is already a tracker to the ow2.asm invalid version bug which you can follow.
Related
My app works great with java 1.8 (and earlier), however when I rebuilt the application to use java 9, I receive the following stack trace. The reason for the update is because I need to use the new ProcessHandle.current(), which does not exist in earlier versions.
c:\>java -jar ./build/bin/DataMover.jar
DataMover Service: starting...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.NoClassDefFoundError: org/glassfish/jersey/server/ResourceConfig
at dataMoverServerPackage.Main.main(Unknown Source)
... 5 more
Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.server.ResourceConfig
at java.base/java.net.URLClassLoader.findClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
For whomever is curious, here is the java version output.
c:\>java -version
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
Here is the relevant main() function.
public static void main(String[] args)
{
try
{
...
final ResourceConfig resourceConfig = new ResourceConfig(DataMoverServerResource.class);
I did research and read that the big difference between Java 6,7,8 and Java 9 is modules. In particular earlier versions of Java included the Java EE JDK, whereas Java 9 includes the java.se module, not the EE. All com.sun.* classes are inaccessible in Java 9, as I read. These pieces of information may or may not be relevant. I do not know the internal makeup of the jersey.server API, just some articles talked of that.
I am using a jar in jar loader, so the jersey stuff is in the base jar.
I am torn between an internal dependency issue on Jersey or the jersey jar. The loader seems happy just fails later at the java.base/jdk.internal, which tells me a module might be missing.
If there were an internal module, such as java.xml.bind, like I read in one post, which is included in Java EE, then the exception trace would indicate that and I would know to add that module using the --add-module option to java, such as --add-module java.xml.bind, but that is not the case here, at least with that module.
Here is a link to one possibly relevant article. Maybe the java.net is the problem, much like the at javax.xml.bind at the bottom of the stack trace in that question was the underlying cause. I discounted the ext folder answer in this question, as that question pertained to 1.8, which works for me and I have jar-in-jar. I note the question here because it keeps turning up on searches. This question was also not relevant, though similar. The list goes on.
I use Eclipse, but build using ant. The Jersey stuff libraries are in my Maven .m2 folder. I did right click on my project and select Maven > Update. That is at 2.7.
I came across this site, which talks about Java 9 migration. In the site, I read that if you add java.se.ee, you will have access to all Java EE modules. That recommendation failed, same output. The command that I tried was:
java --add-modules java.se.ee -jar ./build/bin/DataMover.jar
I did check SO and quite a few other sites but have turned up empty so far. Thoughts?
I am getting this stack trace when running a very basic feature which just opens a browser, navigates to google.com and search some string.
Exception in thread "main" java.lang.NoClassDefFoundError:
org/springframework/transaction/TransactionStatus
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetPublicMethods(Class.java:2902)
at java.lang.Class.getMethods(Class.java:1615)
at cucumber.runtime.java.MethodScanner.scan(MethodScanner.java:40)
at cucumber.runtime.java.JavaBackend.loadGlue(JavaBackend.java:86)
at cucumber.runtime.Runtime.<init>(Runtime.java:92)
at cucumber.runtime.Runtime.<init>(Runtime.java:70)
at cucumber.runtime.Runtime.<init>(Runtime.java:66)
at cucumber.api.cli.Main.run(Main.java:35)
at cucumber.api.cli.Main.main(Main.java:18)
Caused by: java.lang.ClassNotFoundException:
org.springframework.transaction.TransactionStatus
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 11 more
Can someone tell me what is missing here?
For Intellij 2018.1 and i guess for early versions, the Run configuration by default gets the Glue 'cucumber.api.spring' , you should switch it for 'com.foreach.cuke'
Go to 'Edit Configurations' - 'Cucumber' - Glue: com.foreach.cuke ...
The below dependency is missing. Default glue cucumber.api.spring is not able to find class transaction so it throws an error. Add dependency to your pom.xml and it will solve your issue
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
</dependency>
You should switch The Run configuration to 'com.foreach.cuke' instead of 'cucumber.api.spring'..
Go to 'Edit Configurations' - 'Cucumber' - Glue: com.foreach.cuke ...
As far as NoClassDefFoundError is concerned, it arises due to mismatch between the following components :
JDK version - Solution - Keep the JDK version updated to the recent releases.
JUnit version - Solution - Keep the JUnit version in sync with cucumber version.
Selenium version - Solution - Update the Selenium version to the recent release versions.
WebDriver Binary version - Solution - Update the WebDriver version to the recent release versions.
Web Browser Binary version - Solution - Update the Web Browser version to the recent release versions.
I am trying to run another Tomcat instance on the same server. When I deploy application (Maven, Java 8, Guice 3.0, Jersey 1.19) on the first Tomcat 7, it startups and runs well. However, the same application in another Tomcat 7 does not startup properly:
java.util.logging.ErrorManager: 5
com.google.inject.internal.util.$ComputationException: java.lang.ArrayIndexOutOfBoundsException: 57912
at com.google.inject.internal.util.$MapMaker$StrategyImpl.compute(MapMaker.java:553)
at com.google.inject.internal.util.$MapMaker$StrategyImpl.compute(MapMaker.java:419)
at com.google.inject.internal.util.$CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2041)
at com.google.inject.internal.util.$StackTraceElements.forMember(StackTraceElements.java:53)
...
Caused by: java.lang.ArrayIndexOutOfBoundsException: 57912
at com.google.inject.internal.asm.$ClassReader.<init>(Unknown Source)
at com.google.inject.internal.asm.$ClassReader.<init>(Unknown Source)
at com.google.inject.internal.asm.$ClassReader.<init>(Unknown Source)
I have tried on Why is a lambda expression breaking guice error handling when i try to start jetty? discussion answer and switched from Guice 3 to 4 but it didn't change anything.
How to solve this problem?
It works after commenting lambda expressions in the app. However, I forgot that I have included .jar library which also use Guice 3 so after updating it to Guice 4, Tomcat started up:
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>4.1.0</version>
</dependency>
I am using hadoop 2.7.0 and java oracle jdk1.7.0_79 with NetBeans IDE 8.0.2.
When I try to communicate with Hadoop using the Java file, then I get the following error. Is there any dependency issues involved? Or how can I resolve this error?
I have seen posts with related issue, but none of them were helpful to convey the answer clearly. So, please help me out here. Thanks!
Exception in thread "main" org.apache.hadoop.ipc.RemoteException: Server IPC version 9 cannot communicate with client version 4
at org.apache.hadoop.ipc.Client.call(Client.java:1066)
at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:225)
at com.sun.proxy.$Proxy1.getProtocolVersion(Unknown Source)
at org.apache.hadoop.ipc.RPC.getProxy(RPC.java:396)
at org.apache.hadoop.ipc.RPC.getProxy(RPC.java:379)
at org.apache.hadoop.hdfs.DFSClient.createRPCNamenode(DFSClient.java:118)
at org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:222)
at org.apache.hadoop.hdfs.DFSClient.<init>(DFSClient.java:187)
at org.apache.hadoop.hdfs.DistributedFileSystem.initialize(DistributedFileSystem.java:89)
at org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:1328)
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:65)
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:1346)
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:244)
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:187)
at org.apache.hadoop.mapreduce.lib.input.FileInputFormat.setInputPaths(FileInputFormat.java:352)
at pir.PIR.run(PIR.java:317)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
at pir.PIR.main(PIR.java:256)
If you are using maven then, check the version of Hadoop-client you are including in your POM file. It might be older version than the current hadoop running version on your cluster (it should be 2.7.0)
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>2.7.0</version>
</dependency>
I have Jenkins of 1.611 version, JDK 1.7 and remote WAS8.5 is running on JDK 1.6 version. When I am trying to deploy EAR or WAR file by the help of Github (i.e., I am pushing the project from eclipse Luna which has java 7 configuration), Iam facing the following error:
Connecting to IBM WebSphere Application Server...
The following artifacts will be deployed in this order...
-------------------------------------------
SpringWSEAR.ear
-------------------------------------------
Error deploying to IBM WebSphere Application Server: org.jenkinsci.plugins.websphere.services.deployment.DeploymentServiceException:
at org.jenkinsci.plugins.websphere.services.deployment.WebSphereDeploymentService.getAppName(WebSphereDeploymentService.java:122)
at org.jenkinsci.plugins.websphere.services.deployment.WebSphereDeploymentService.getAppName(WebSphereDeploymentService.java:98)
at org.jenkinsci.plugins.websphere_deployer.WebSphereDeployerPlugin.getAppName(WebSphereDeployerPlugin.java:268)
at org.jenkinsci.plugins.websphere_deployer.WebSphereDeployerPlugin.createArtifact(WebSphereDeployerPlugin.java:226)
at org.jenkinsci.plugins.websphere_deployer.WebSphereDeployerPlugin.perform(WebSphereDeployerPlugin.java:168)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:764)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:724)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
at hudson.model.Run.execute(Run.java:1769)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Caused by: com.ibm.websphere.management.application.client.AppDeploymentException: [Root exception is java.lang.IncompatibleClassChangeError: Implementing class]
at com.ibm.websphere.management.application.AppManagementFactory.handleException(AppManagementFactory.java:672)
at com.ibm.websphere.management.application.AppManagementFactory.readArchive(AppManagementFactory.java:141)
at com.ibm.websphere.management.application.AppManagementFactory.readArchive(AppManagementFactory.java:91)
at com.ibm.websphere.management.application.client.AppDeploymentController.readArchive(AppDeploymentController.java:254)
at org.jenkinsci.plugins.websphere.services.deployment.WebSphereDeploymentService.getAppName(WebSphereDeploymentService.java:108)
... 13 more
Caused by: java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at jenkins.util.AntClassLoader.defineClassFromData(AntClassLoader.java:1139)
at hudson.ClassicPluginStrategy$AntClassLoader2.defineClassFromData(ClassicPluginStrategy.java:799)
at jenkins.util.AntClassLoader.getClassFromStream(AntClassLoader.java:1310)
at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1366)
at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1326)
at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1079)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at jenkins.util.AntClassLoader.defineClassFromData(AntClassLoader.java:1139)
at hudson.ClassicPluginStrategy$AntClassLoader2.defineClassFromData(ClassicPluginStrategy.java:799)
at jenkins.util.AntClassLoader.getClassFromStream(AntClassLoader.java:1310)
at jenkins.util.AntClassLoader.findClassInComponents(AntClassLoader.java:1366)
at jenkins.util.AntClassLoader.findClass(AntClassLoader.java:1326)
at jenkins.util.AntClassLoader.loadClass(AntClassLoader.java:1079)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.WARFileImpl.getWARFileAnnotationsDetector(WARFileImpl.java:2908)
at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.WARFileImpl.containsEJBContent(WARFileImpl.java:1975)
at com.ibm.ws.management.application.client.AppInstallHelper.checkForXmiFiles(AppInstallHelper.java:1372)
at com.ibm.ws.management.application.client.AppInstallHelper.checkForXmiFiles(AppInstallHelper.java:1331)
at com.ibm.ws.management.application.client.AppInstallHelper.checkForEE5Restrictions(AppInstallHelper.java:512)
at com.ibm.ws.management.application.client.AppInstallHelper.checkForEE5Restrictions(AppInstallHelper.java:477)
at com.ibm.ws.management.application.client.AppInstallHelper.getAppDeploymentInfo(AppInstallHelper.java:563)
at com.ibm.websphere.management.application.AppManagementFactory.readArchive(AppManagementFactory.java:129)
... 16 more
Build step 'Deploy To IBM WebSphere Application Server' changed build result to FAILURE
Finished: FAILURE
Is there any version differences between eclipse or jenkins or WAS???
Any Help would be appreciated...
This is a known issue with the WebSphere Deployer Plugin, of which you appear to have filed a duplicate on the Jenkins issue tracker.
The latest comments on that issue indicate that a fix has been made, but this has not yet been released.
Its got resolved.. I have been using WAS8.5 jars which were running on JDK 1.7. I have replaced those by JDK 1.6 jars. And deployed successfully. Thank you..