-
Task
-
Resolution: Done
-
Blocker
-
jbossws-jaxws-tools-maven-plugin-1.2.0.Beta1
-
None
When running on JDK9 plugin fails with CNFE classes from jaxb impl
Maybe fix would be as simple as using jaxb-ri 2.3 dependency explicitly.
Caused by: java.lang.NoClassDefFoundError: com/sun/istack/FinalArrayList
at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:246)
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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:137)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:108)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:286)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:279)
at org.apache.cxf.tools.wsdlto.core.PluginLoader.init(PluginLoader.java:78)
at org.apache.cxf.tools.wsdlto.core.PluginLoader.<init>(PluginLoader.java:73)
at org.apache.cxf.tools.wsdlto.core.PluginLoader.newInstance(PluginLoader.java:106)
at org.apache.cxf.tools.wsdlto.WSDLToJava.<init>(WSDLToJava.java:48)
at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:308)
at org.jboss.ws.api.tools.WSContractConsumer.consume(WSContractConsumer.java:225)
... 29 more
[JBWS-4075] jaxws-tools-maven-plugin doesn't work on JDK9
Tools using this plugin will need to make the adjustments.
There is always backward compatibility aspect we should keep in mind.
I'd rather see fix which would not require changes on end user or other tools side
Created https://issues.jboss.org/browse/WFLY-9984 jaxws-retail fails to build with jdk-9
to implement workaround.
So there is no change to be made to jaxws-tools-maven-plugin itself.
Tools using this plugin will need to make the adjustments.
The team will need to follow up with apache about WSDLToJava.
There is an apache code issue that pertains to use with JDK-9 but there
is a workaround for it.
The root cause of the failure is org/apache/cxf/tools/wsdlto/WSDLToJava (version 3.2.2)
is calling the java compiler programmatically and this is failing when using jdk-9.
Workaround for JDK-9.
1. Just as org.jboss.ws.cxf:jbossws-cxf-client is required to be added as a
dependency to the pom file using the jaxws-tools-maven-plugin, now
gnu.getopt:java-getopt:1.0.13 must be added as well.
<dependency>
<groupId>gnu.getopt</groupId>
<artifactId>java-getopt</artifactId>
<version>1.0.13</version>
</dependency>
2. jaxws-tools-maven-plugin's configuration option "fork" must be set to "true"
<configuration>
<fork>true</fork>
:
:
</configuration>
fork=true forces the utility to be executed from the cmd-line and not
run via org/apache/cxf/tools/wsdlto/WSDLToJava.
Tomaž Cerar (Inactive)
added a comment - To reproduce the issue, checkout quickstarts from https://github.com/wildfly/quickstart
go to folder jaxws-retail and run mvn clean install.
on jdk8 it works, on 9/10/11 it breaks.
It is a small project and you can easily reproduce it there.
Tomaž Cerar (Inactive)
added a comment - To reproduce the issue, checkout quickstarts from https://github.com/wildfly/quickstart
go to folder jaxws-retail and run mvn clean install.
on jdk8 it works, on 9/10/11 it breaks.
It is a small project and you can easily reproduce it there. This block jaxws-* quickstarts on Java 9+
rhn-support-asoldano, could it be prioritized. please?
The specific exception described in this jira was more related to the code having old
versions of dependency archives. Fixing that addressed an issue with the testcases
failing and exceptions given by the tool. Jira https://issues.jboss.org/browse/JBWS-4092 was created to checkin these changes.
It is unclear if the JBWS-4092 changes are sufficient for this tool to be used with jdk9. This
is because this tool requires archive org.jboss.ws.cxf:jbossws-cxf-client. I have not been
able to successfully run my test app with the version changes, org.jboss.ws.cxf:jbossws-cxf-client:5.2.0.Final and JDK9. I have not been able to build jbossws-cxf branch jdk9 with any version of JDK9.
jbossws-cxf-client references classes javax.tools.JavaFileManager, javax/tools/DiagnosticListener. These are exported from module java.compile. My test app
reports NoClassDefFoundError expections for classes. I have not found a way to address
this issue.
Be sure to use an Oracle JDK not some other.
I saw this issue from the built in JRE8 that IntelliJ provides and was using with Maven by default. Force Maven JDK to be an actual Oracle one and this error went away.
Darryl Miles (Inactive)
added a comment - - edited Be sure to use an Oracle JDK not some other.
I saw this issue from the built in JRE8 that IntelliJ provides and was using with Maven by default. Force Maven JDK to be an actual Oracle one and this error went away. I have not been able to reproduce the error documented but there were issues with the project tests. I've updated the archive versions. This cleaned up the test failures. I
hope it will resolve your issue as well.
Please rebuild this code with jdk 8
https://github.com/rsearls/jaxws-tools-maven-plugin/tree/JBWS-4075-working-on-jdk9
and test the plugin in your jdk9 env.
I suggest overriding user's choice of fork option with 'true' when jdk9 is used, basically because in that case we need to explicitly add the java.compiler module.
As for the gnu getopt dependency having to be explicitly declared when on fork mode, I believe this is a bug I erroneously introduced back in 2011 when working on
JBWS-3400; the plugin has to get the dependency from its own dep tree, without having to rely on the project it's included in.I have preliminary fix in a branch of mine, see https://github.com/jbossws/jaxws-tools-maven-plugin/compare/master...asoldano:JBWS-4075 . Rebecca is taking over from here (a couple of tests are still failing).