[
https://issues.apache.org/jira/browse/CXF-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034575#comment-17034575
]
Marian Macik commented on CXF-7925:
-----------------------------------
Hi guys, is this under some dicussion or should we close this?
> Dynamic WSDL Client creation fails on JDK 11 because it cannot compile
> generated classes
> ----------------------------------------------------------------------------------------
>
> Key: CXF-7925
> URL: https://issues.apache.org/jira/browse/CXF-7925
> Project: CXF
> Issue Type: Bug
> Components: Core, JAX-WS Runtime
> Affects Versions: 3.1.16, 3.2.7
> Environment: JDK 11
> Wildfly 14/EAP 7.2.0
> Apache CXF 3.1.16/3.2.7
> Reporter: Marian Macik
> Priority: Major
> Labels: Java11, jdk11
>
> Hi guys,
> sorry for a longer description, but I wrote here everything I know.
> I am working on kiegroup projects (drools,jbpm,optaplanner) and we are now
> upgrading to JDK 11. I am having the following issue (it works on JDK 8):
> Enivornment is JDK 11, Wildfly 14/EAP 7.2.0 and I am running there our tests.
> The test runs inside EAP and calls a
> [WebService|https://github.com/kiegroup/jbpm/blob/ccddd0812225ec7666111700e4138d3a32a28b66/jbpm-container-test/jbpm-remote-ejb-test/jbpm-remote-ejb-test-suite/src/main/java/org/jbpm/remote/ejb/test/mock/WebService.java#L32-L37]
> which is published from client side (outside container)
> [here|https://github.com/kiegroup/jbpm/blob/ccddd0812225ec7666111700e4138d3a32a28b66/jbpm-container-test/jbpm-remote-ejb-test/jbpm-remote-ejb-test-suite/src/main/java/org/jbpm/remote/ejb/test/mock/WebService.java#L47].
> So basically a code in the container is trying to connect to a WebService not
> deployed on that container.
> At first, the test creates a dynamic client
> [here|https://github.com/kiegroup/jbpm/blob/master/jbpm-workitems/jbpm-workitems-webservice/src/main/java/org/jbpm/process/workitem/webservice/WebServiceWorkItemHandler.java#L410]
> (classloader used is *Thread.currentThread().getContextClassLoader()*, its
> toString method says "ModuleClassLoader for Module
> "deployment.ejb-services-app.war" from Service Module Loader" - so it is
> basically a classloader for the deployed application), but it fails to do
> that with an exception:
> *Unable to create JAXBContext for generated packages: "org.jboss.sepro"
> doesnt contain ObjectFactory.class or jaxb.index*
> However, this is not the root cause. I debugged it and the root cause is
> following. When the client is being created, it downloads WSDL and then
> creates a classes for marshalling/unmarshalling using XJC. Classes are
> generated, I can find them in /tmp folder which is created by the code in
> [DynamicClientFactory.java|https://github.com/apache/cxf/blob/4f9923c32688c57e31f933c69d9c2a667f20d63d/rt/frontend/simple/src/main/java/org/apache/cxf/endpoint/dynamic/DynamicClientFactory.java#L366].
> After that, it's time for compilation which unfortunately fails in
> [DynamicClientFactory#compileJavaSrc|https://github.com/apache/cxf/blob/4f9923c32688c57e31f933c69d9c2a667f20d63d/rt/frontend/simple/src/main/java/org/apache/cxf/endpoint/dynamic/DynamicClientFactory.java#L389].
> When I dug deeper, I found that the classpath for compilation is set to ""
> (or rather not set) in
> [DynamicClientFactory#setupClasspath|https://github.com/apache/cxf/blob/4f9923c32688c57e31f933c69d9c2a667f20d63d/rt/frontend/simple/src/main/java/org/apache/cxf/endpoint/dynamic/DynamicClientFactory.java#L674]
> method. I guess this is fine, since it is only filled in case a
> URLClassLoader is used or in case we are in WebLogic, so there is a weblogic
> classloader. But since we are using just
> Thread.currentThread().getContextClassLoader(), which is not of type
> URLClassLoader, it does nothing. Then, before the compilation itself, CXF
> sets arguments for a compiler in
> [Compiler#addArgs|https://github.com/apache/cxf/blob/4f9923c32688c57e31f933c69d9c2a667f20d63d/core/src/main/java/org/apache/cxf/common/util/Compiler.java#L104]
> method. Here you can see it uses
> [java.class.path|https://github.com/apache/cxf/blob/4f9923c32688c57e31f933c69d9c2a667f20d63d/core/src/main/java/org/apache/cxf/common/util/Compiler.java#L105]
> system property to set the classpath. However, since we are on EAP, the
> java.class.path is set to:
> */home/mmacik/Workspace/jbpm/jbpm-container-test/jbpm-remote-ejb-test/jbpm-remote-ejb-test-suite/target/cargo/installs/jboss-eap-7.2.0.GA.CR2/jboss-eap-7.2/jboss-modules.jar*
> and that's it. The code doesn't pass there anything else, just this one JAR
> file.
> And now why it fails. I copied the classes generated by XJC and tried to
> compile them by myself (since programmatic way returns only true/false) using
> javac and they doesn't compile since JAXB annotations (JAXP-API classes in
> general) are not on the classpath. The reason is that in Java 11 these
> classes were removed as part of [JEP-320|https://openjdk.java.net/jeps/320]
> document. So on Java 8 it works, although the classpath is set to only
> jboss-modules.jar as well, because Java 8 contains required
> annotations/classes from JAXB-API in itself. When I tried to compile these
> generated classes manually using JDK 11 and I included jaxb-api artifact on
> classpath using -classpath option, they compiled.
> So ultimately the test fails on JAXBContext creation because it cannot find
> ObjectFactory.class or jaxb.index file, which is completely fine since it
> didn't compile.
> So I think that now it is not possible to use Dynamic Client with WSDL in
> Wildfly/EAP since generated classes won't compile. And it doesn't matter
> which classloader we use since the classpath is obtained from java.class.path
> system property, unless we use URLClassLoader or we are in Weblogic so we can
> use a WebLogic classloader.
> We have also a vice-versa test, meaning the test calls a WebService, which is
> deployed in EAP, from outside the container. This scenario works with JDK 11
> as well as with JDK 8 because system property java.class.path contains all
> Maven dependencies needed to build and run the tests (dynamic client creation
> now happens as a part of a jUnit test in a failsafe plugin).
> So do you have any ideas/hints/recommendations how to overcome this or is
> this going to be fixed in the near future for JDK 11?
> Thank you very much.
> Marian Macik
> Red Hat Business Automation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)