I'm trying to use Hyperjaxb3 with Apache CXF to generate persistence annotations from a WSDL-first web service. I've plugged the Hyperjaxb3-ejb-plugin into the cxf-codegen-plugin, like so.
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>${cxf.version}</version>
<dependencies>
<dependency>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>0.5.2</version>
</dependency>
<dependency>
<groupId>org.jvnet.hyperjaxb3</groupId>
<artifactId>hyperjaxb3-ejb-plugin</artifactId>
<version>0.5.4</version>
</dependency>
</dependencies>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/resources/wsdl/CDXLEAToCourt.wsdl</wsdl>
<xjcargs>
<xjcarg>-Xequals</xjcarg>
<xjcarg>-XtoString</xjcarg>
<xjcarg>-Xhyperjaxb3-ejb</xjcarg>
</xjcargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
When I generate source, I get the following informative stack trace.
Failed to execute goal org.apache.cxf:cxf-codegen-plugin:2.2.7:wsdl2java (generate-sources) on project leaToCourtWS: Failed to generate types. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.cxf:cxf-codegen-plugin:2.2.7:wsdl2java (generate-sources) on project leaToCourtWS: Failed to generate types.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:585)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:324)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:427)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:121)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to generate types.
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:409)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:361)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:577)
... 14 more
Caused by: org.apache.cxf.tools.common.ToolException: Failed to generate types.
at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.generate(JAXBDataBinding.java:716)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:582)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:228)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:128)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:271)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:406)
... 17 more
I've been banging my head against this for a while. I tried to continue the project without Hyperjaxb, but don't want to incur the maintenance costs. Any ideas? A solution to the exception- or an alternative to using Hyperjaxb- would be great.
Found a solution. I emailed Aleksei - the project owner- and he informed me that Hyperjaxb3 CXF integration was introduced in .5.5, which has yet to be released. D'oh!
He suggested I use the snapshot repository. I added the repository to my POM, changed the version of the hyperjaxb3-ejb-plugin to 0.5.5-SNAPSHOT- and so far, everything works beautifully.
It seems the problem comes from your WSDL file.
There is a working example within the source code of Hyperjaxb3 called customerservice-cxf that might help you.
Related
i'm trying to generate class stubs for a wsdl with Intellij-Idea 2017.2.5 (Webservices -> Generate code from wsdl...) using JDK-9
I'm getting this exception and i wonder how to tell intellij to pass "--add-modules java.activation" to complete the operation.
(i guess i should run wsimport from the command line...)
Exception in thread "main" java.lang.NoClassDefFoundError: javax/activation/DataSource
at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl.<clinit>(RuntimeBuiltinLeafInfoImpl.java:461)
at com.sun.xml.bind.v2.model.impl.RuntimeTypeInfoSetImpl.<init>(RuntimeTypeInfoSetImpl.java:65)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:133)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:85)
at com.sun.xml.bind.v2.model.impl.ModelBuilder.<init>(ModelBuilder.java:156)
at com.sun.xml.bind.v2.model.impl.RuntimeModelBuilder.<init>(RuntimeModelBuilder.java:93)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:455)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:303)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:142)
at com.sun.xml.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1174)
at com.sun.tools.xjc.reader.xmlschema.bindinfo.BindInfo.getJAXBContext(BindInfo.java:335)
at com.sun.tools.xjc.reader.internalizer.SCDBasedBindingSet.apply(SCDBasedBindingSet.java:235)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:541)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:269)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:95)
at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:142)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2244)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:191)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:137)
at com.sun.tools.ws.wscompile.WsimportTool.buildWsdlModel(WsimportTool.java:391)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:204)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:179)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at com.sun.tools.ws.Invoker.invoke(Invoker.java:135)
at com.sun.tools.ws.WsImport.main(WsImport.java:57)
Caused by: java.lang.ClassNotFoundException: javax.activation.DataSource
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
... 28 more
Based on your error message, you need to add the following dependency in your pom.xml
<dependency>
<groupId>javax.activation</groupId>
<artifactId>activation</artifactId>
<version>1.1.1</version>
</dependency>
From SDK 9, for JAXB to work for web services you need to also have the following dependencies if you do not already have them as they are not part of the SDK.
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-core</artifactId>
<version>2.3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.3.0</version>
</dependency>
I guess it can be useful. I have these additional packages in my soap project when switch from Java 8 to 10. Gradle:
compile "javax.xml.bind:jaxb-api:2.3.0"
compile "javax.activation:activation:1.1"
compile "com.sun.xml.bind:jaxb-impl:2.3.0"
compile "com.sun.xml.bind:jaxb-core:2.3.0"
compile "com.sun.xml.ws:rt:2.3.0"
compile "com.sun.xml.ws:jaxws-rt:2.3.0"
Just for other people with the same exception coming here:
This problem can also occur if you use a web server such as tomcat and if you need the activation jar to be present there as well. One possible solution is to put it in the lib folder of tomcat (or to use the common.loader functionality).
I had the same problem. After changing the project jdk, it works for me.
Change project jdk to 8.
I have a Google App Engine Standard Maven project, which I created with the appengine-standard-archetype archetype.
I want to use the ${project.version} variable as deploy version, but the value is not allowed for certain characters:
May only contain lowercase letters, digits, and hyphens. Must begin
and end with a letter or digit. Must not exceed 63 characters.
The value 0.0.1-SNAPSHOT need to be modified. I then used the build-helper-maven-plugin to obtain the replacement
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>version-urlsafe</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>project.version.urlsafe</name>
<value>${project.version}</value>
<regex>\.</regex>
<replacement>-</replacement>
<toLowerCase>true</toLowerCase>
<failIfNoMatch>false</failIfNoMatch>
</configuration>
</execution>
</executions>
</plugin>
And the maven-antrun-plugin to show the value
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>regex-replace-echo</id>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>******** Displaying value of property ********</echo>
<echo>${project.version.urlsafe}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
At the end I used the new property as version for deploy
<app.deploy.version>${project.version.urlsafe}-urlsafe</app.deploy.version>
Note that I add the -urlsafe at the end of the value only to understand why the value is not considered
Running the deploy with mvn appengine:deploy I'm getting this output
...
[INFO] Executing tasks
main:
[echo] ******** Displaying value of property ********
[echo] 0-0-1-snapshot
...
gcloud.cmd app deploy --version ${project.version.urlsafe}-urlsafe
[INFO] GCLOUD: ERROR: (gcloud.app.deploy) argument --version/-v: Bad value [${project.version.urlsafe}-urlsafe]
Even if the ant-run plugin properly echoed the new version, when the deploy command is built, the variable itself is missing.
I then tried forcing the regex-property goal before the deploy, like follows
mvn build-helper:regex-property appengine:deploy
but I'm getting a missing configuration error in this case:
[ERROR] Failed to execute goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:regex-property (default-cli) on project maventest: The parameters 'regex', 'name', 'value' for goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:regex-property are missing or invalid -> [Help 1]
A little digression:
I decided to manually run the build-helper:regex-property as additional goal due to a previous experience with a similar a case: a plugin that inject a new variable, which is properly echoed but when it comes to use the value, is missing. Here is the reference: Unable to obtaing git.branch property
Cooperating with the plugin author we found that adding the plugin goal before the appengine one can solve the issue mvn git-commit-id:revision appengine:deploy. At the end the root cause of this problem was a Maven bug: https://issues.apache.org/jira/browse/MNG-6260
So even the workaround of directly calling the plugin is not suitable in this case due to a plugin configuration error.
How can issue can be solved? How can I obtain the ${project.version.urlsafe} variable properly created when executing the appengine deploy?
I had the same problem using the appengine-maven-plugin. And you're right, you need to first call the goal build-helper:regex-property before deploying on app engine.
But to make this work, you have to move the configuration part outside the executions tag.
Here is the complete configuration I am currently using:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<configuration>
<name>project.version.urlsafe</name>
<value>${project.version}</value>
<regex>\.</regex>
<replacement>-</replacement>
<toLowerCase>true</toLowerCase>
<failIfNoMatch>false</failIfNoMatch>
<fileSet/>
<source/>
</configuration>
</plugin>
Then when calling mvn build-helper:regex-property appengine:deploy, everything should work as expected.
When I using the follow structure on our Maven project:
<plugins>
<plugin>
<groupId>org.scala-tools</groupId>
<artifactId>maven-scala-plugin</artifactId>
<version>2.15.2</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
<configuration>
<args>
<arg>-g:line</arg>
</args>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.5.8.201207111220</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
The tests are executed but the jacoco.exec file is not created. I tried to add this tag destFile to prepare-agent goal but have not success (the file with coverage information is not created).
Anyone have any form to calculate code coverage of unit test for Scala using maven and Jacoco?
Work of Jacoco maven plugin depends on versions of JDK, Scala and plugin itself.
Just added the same config and it works properly: both jacoco.exec and site/jacoco with reports are in the target dir: https://github.com/plokhotnyuk/calculator/commit/e3a84db02dd942b0df71d4fa337df29512e213f6
Then got agent failure when using latest (0.6.2.201302030002) version of Jacoco maven plugin:
Caused by: java.lang.RuntimeException: Class java/util/UUID could not be instrumented.
at org.jacoco.agent.rt.internal_5d10cad.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138)
at org.jacoco.agent.rt.internal_5d10cad.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:99)
at org.jacoco.agent.rt.internal_5d10cad.PreMain.createRuntime(PreMain.java:51)
at org.jacoco.agent.rt.internal_5d10cad.PreMain.premain(PreMain.java:43)
... 6 more
Caused by: java.lang.NoSuchFieldException: $jacocoAccess
at java.lang.Class.getField(Class.java:1542)
at org.jacoco.agent.rt.internal_5d10cad.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:136)
... 9 more
FATAL ERROR in native method: processing of -javaagent failed
Exception in thread "main"
And then the failure was worked out by switching from JDK8 to JDK7. Coverage report digits didn't changed.
Also after switching to Scala 2.10 source line highlighting started looks different:
Scala 2.9
Scala 2.10
I am getting the below exception when I try to run a simple jMockit/JUnit test using IBM JDK. Has anyone faced this issue? I tried given -Dcom.ibm.tools.attach.enable=yes as VM argument but no luck. The same code is working fine in Sun JDK.
java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to enqueue operation: the target VM does not support attach mechanism
at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:89)
at mockit.internal.startup.JDK6AgentLoader.loadAgent(JDK6AgentLoader.java:54)
at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:21)
at mockit.internal.startup.Startup.initializeIfNeeded(Startup.java:98)
at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:112)
at org.junit.runner.Runner.<clinit>(Runner.java:22)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
at org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to enqueue operation: the target VM does not support attach mechanism
at sun.tools.attach.WindowsVirtualMachine.<init>(WindowsVirtualMachine.java:64)
at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:73)
... 22 more
java.lang.NoClassDefFoundError: org.junit.internal.runners.ErrorReportingRunner (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:140)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.NoClassDefFoundError: org.junit.runner.Runner (initialization failure)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:140)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
... 9 more
Caused by: java.lang.RuntimeException: com.sun.tools.attach.AttachNotSupportedException: Unable to enqueue operation: the target VM does not support attach mechanism
at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:89)
at mockit.internal.startup.JDK6AgentLoader.loadAgent(JDK6AgentLoader.java:54)
at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:21)
at mockit.internal.startup.Startup.initializeIfNeeded(Startup.java:98)
at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:112)
at org.junit.runner.Runner.<clinit>(Runner.java:22)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:167)
at org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
... 11 more
Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to enqueue operation: the target VM does not support attach mechanism
at sun.tools.attach.WindowsVirtualMachine.<init>(WindowsVirtualMachine.java:64)
at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:73)
... 22 more
I tried giving the VM argument -javaagent:jmockit.jar as suggested by Kevin Welker and I got the below exception.
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:335)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:350)
Caused by: java.lang.NullPointerException
at mockit.internal.annotations.MockClassSetup.validateRealClass(MockClassSetup.java:59)
at mockit.internal.annotations.MockClassSetup.<init>(MockClassSetup.java:38)
at mockit.internal.annotations.MockClassSetup.<init>(MockClassSetup.java:77)
at mockit.internal.annotations.MockClassSetup.<init>(MockClassSetup.java:99)
at mockit.internal.startup.JMockitInitialization.setUpInternalStartupMock(JMockitInitialization.java:56)
at mockit.internal.startup.JMockitInitialization.initialize(JMockitInitialization.java:29)
at mockit.internal.startup.Startup.initialize(Startup.java:68)
at mockit.internal.startup.Startup.premain(Startup.java:56)
... 6 more
Fatal error: processing of -javaagent failed
The Attach API simply doesn't work in the IBM JDK 6.0, at least on Windows. Therefore, it's necessary to use the -javaagent:jmockit.jar parameter.
The NullPointerException that occurs at MockClassSetup.java:59, when using -javaagent, is caused by a bug in the IBM JDK. When a type referenced in an annotation attribute (#MockClass, in this case) is not present in the classpath, the JDK should throw a TypeNotPresentException. The Oracle JDKs do so as expected, but the IBM JDK returns null instead for the attribute value.
I just implemented a workaround for this in class MockClassSetup, which will be available in the next JMockit release, by the end of september. For now, you can avoid the problem by adding TestNG to the classpath (since the "type not found" is the org.testng.TestNG class).
Above answer to use -javaagent is correct. If you're using maven it's a little tricky, so here is how I did it:
Add the maven-dependency-plugin so you can generate absolute paths to the dependencies:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<id>getClasspathFilenames</id>
<goals>
<goal>properties</goal>
</goals>
</execution>
</executions>
</plugin>
2. Add -javaagent to surefire plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.13</version>
<configuration>
<argLine>-javaagent:${com.googlecode.jmockit:jmockit:jar} -XX:-UseSplitVerifier</argLine>
</configuration>
</plugin>
3. Also, you don't have to, but I'd recommend using a relatively newer version of jmockit. This issues was detected in 1.1 (prior to September 2012 fix by #Rogério, but adding -javaagent fixes it regardless. For reference I am using the latest version available in maven central (2.5) as of this comment:
<dependency>
<groupId>com.googlecode.jmockit</groupId>
<artifactId>jmockit</artifactId>
<!-- Use latest version. 1.1 gives AttachNotSupportedException -->
<version>1.5</version>
<scope>test</scope>
</dependency>
Certain versions of the IBM JDK do not properly support the attach mechanism. You might try running with -javaagent:jmockit.jar parameter. The following info is a bit old, but it may still apply as other JDKs do not necessarily fully support the attach mechanism.
See this: http://code.google.com/p/jmockit/issues/detail?id=18
I also tried using JMockit to override final methods in a class in a 3rd party library. I got the same problem discussed above, and again adding the VM arg -javaagent:C:/<Path-to-jar>/jmockit.jar only gave me a different type of error. I am also using the IBM JDK 6.0 that comes with Websphere. It's a shame but it looks like it is an actual impossibility to override final methods: I can't find any other Testing framework that can do it.
You just need update the JDK to 1.8. I tested this version JDK, and this problem has been resolved.
The setup for javagent for surefire using maven looks like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.18.1</version>
<configuration>
....
<argLine>-javaagent:"${settings.localRepository}"/org/jmockit/jmockit/1.11/jmockit-1.11.jar</argLine>
</configuration>
</plugin>
The above assumes you are using the following dependency:
<dependency>
<groupId>org.jmockit</groupId>
<artifactId>jmockit</artifactId>
<version>1.11</version>
<scope>test</scope>
</dependency>
If you are using a different version then modify the argLine value appropriately.
Source: http://jmockit.googlecode.com/svn-history/r1166/trunk/www/installation.html
Hoping for some feedback on this issue that has been troubling for a while.
I use maven for building a simple web services client application.
It uses several wsdls ( around 8 ) the wsdls have xsd imports ( roughly 2 per wsdl for each request and response, plus a good amount of additional imports ) to generate the java code using a maven cxf wsdl2java plugin.
I started with the plugin version 2.1.7 tried several 2.2.x and now trying with version 2.3.4 of the plugin.
Here is the plugin section of my pom file:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.3.4</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<defaultOptions>
<noAddressBinding>true</noAddressBinding>
</defaultOptions>
<wsdlRoot>${basedir}/src/main/resources/wsdl</wsdlRoot>
<includes>
<include>*.wsdl</include>
</includes>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
I can provide a previous version of how this used to work for me in the past. Basically I had each individual wsdl listed as a < wsdloption > item.
The only thing that I did "environment" related was that for a separate project I deleted everything in my m2 folder. Since then doing the code generation gives me the following error message( using "mvn -e generate-sources" from the command ):
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to generate types.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to generate types.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:584)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to generate types.
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:413)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:362)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
Caused by: org.apache.cxf.tools.common.ToolException: Failed to generate types.
at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.generate(JAXBDataBinding.java:745)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:599)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:247)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138)
at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:290)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:410)
... 19 more
One thing that I've noticed is that in the target/generated-sources folder it creates the same classes in the \generated-sources\cxf\generated AND \generated-sources\org\opentravel\ota_2003_05. Not exactly sure if there is an error in the XSDs or the wsdl themselves.
I have looked for a good explanation of the error and haven't found a solution yet. I have done my fair share of "googling" for this particular issue. Starting to get desperate and hope I can find a solution soon.
Thanks in advance for any help you can provide.
I see this from time to time, when I am using the cxf java plugin, I think the cxf.maven.wsdl2javaMojo run out of memory.
in this case,
I would recommend you to break the each wsdl generation into sub-modules,
increase the maven memory
if it still stops at the middle try to using the mvn Goals -rf :WhereStops command, so it starts at the sub-module which run out memory, thus you don't have to start all over again.
Note I use Maven 3.2
if you not sure how -rf works google mvn -rf
Not really sure. I just looked at the code at that line number and, unfortunately, just discovered that it's completely swallowing an IOException at that point. Thus, I have no idea how to get the real "cause" of that IOException. I'm going to fix that and get it committed to trunk. If you could retry with the latest snapshots tomorrow or monday (after the nightly deploy builds), it should likely provide a much better/complete error message.