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

Reply via email to