quarkiverse / quarkus-cxf

Quarkus CXF Extension to support SOAP based web services.
Apache License 2.0
72 stars 57 forks source link

CxfClient with ComplexTypes fails on subsequent re-runs of quarkus test. #1326

Open akil-rails opened 3 months ago

akil-rails commented 3 months ago

Had reported it in the main repo, but have been asked to raise here --

Describe the bug

  1. When a CxfClient that has only primitive types is injected in a @QuarkusTest, all works fine (including re-runs of the test)
  2. When a CxfClient that has a complex type is injected in a @QuarkTest, the test passes once, and fails on every subsequent re-run, and works again when quarkus test is exited and re-started
  3. When 2 CxfClient's are injected in separate @QuarkusTest, neither tests pass, one has to be commented out.

Expected behavior

  1. CxfClient with Complex Types should support continuous tests (quarkus test - re-run)
  2. Multiple CxfClient should work without causing conflicts with each other.

Actual behavior

No response

How to Reproduce?

Reproducer The steps are mentioned in ReadMe.

Output of uname -a or ver

Darwin Akhileshs-Air.domain.name 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:19:22 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8112 arm64

Output of java -version

openjdk version "21" 2023-09-19 LTS OpenJDK Runtime Environment Temurin-21+35 (build 21+35-LTS) OpenJDK 64-Bit Server VM Temurin-21+35 (build 21+35-LTS, mixed mode)

Quarkus version or git rev

3.9.1

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae) Maven home: /Users/akil/.m2/wrapper/dists/apache-maven-3.9.6-bin/3311e1d4/apache-maven-3.9.6 Java version: 21, vendor: Eclipse Adoptium, runtime: /Users/akil/.sdkman/candidates/java/21-tem Default locale: en_IN, platform encoding: UTF-8 OS name: "mac os x", version: "14.4.1", arch: "aarch64", family: "mac"

Additional information

Adding a @RequestWrapper annotation removes this error - but this annotation is optional, and should not be required.

ppalaga commented 3 months ago

Thanks for the report and especially for the reproducer @akil-rails!

It is a naming clash. When generating the ancillary classes, the default name of the operation is taken from the method name. Then for the two sayHello methods only one com.spliceforms.jaxws_asm.SayHello class is generated that suits only one of the services.

There are several ways how you can work around the issue:

Let me check whether/how we can fix it.

ppalaga commented 3 months ago

I'd say the issue is in CXF code around here:

https://github.com/apache/cxf/blob/80c92d57ab7c34f59d51c3b30d0db9ab074e8c6b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spi/WrapperClassLoader.java#L92-L97

It looks like the class name is not taken into account when creating the name of the generated request and response class.

For the record, here is the stack trace from the reproducer:

 java.lang.IllegalArgumentException: argument type mismatch
[WARNING] [stderr]      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[WARNING] [stderr]      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[WARNING] [stderr]      at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[WARNING] [stderr]      at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[WARNING] [stderr]      at org.apache.cxf.databinding.AbstractWrapperHelper.createWrapperObject(AbstractWrapperHelper.java:114)
[WARNING] [stderr]      at org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:91)
[WARNING] [stderr]      at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
[WARNING] [stderr]      at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
[WARNING] [stderr]      at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:441)
[WARNING] [stderr]      at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:356)
[WARNING] [stderr]      at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314)
[WARNING] [stderr]      at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
[WARNING] [stderr]      at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:140)
[WARNING] [stderr]      at jdk.proxy6/jdk.proxy6.$Proxy132.sayHello(Unknown Source)
[WARNING] [stderr]      at com.spliceforms.NoWsdlClient2Test.testSayHello(NoWsdlClient2Test.java:22)
ppalaga commented 3 months ago

I have filed this CXF issue: https://issues.apache.org/jira/browse/CXF-9003

On Quarkus CXF side, we could at least make the class generation fail at build time when this kind of a clash happens.