[jira] [Commented] (CXF-7925) Dynamic WSDL Client creation fails on JDK 11 because it cannot compile generated classes

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (CXF-7925) Dynamic WSDL Client creation fails on JDK 11 because it cannot compile generated classes

Ivan Topić (Jira)

    [ 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)