quarkus-cxf icon indicating copy to clipboard operation
quarkus-cxf copied to clipboard

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

Open akil-rails opened this issue 10 months ago • 3 comments

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.

akil-rails avatar Apr 01 '24 15:04 akil-rails

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:

  • Move one of the interfaces into a new java package
  • Use different method names
  • Use @jakarta.jws.WebMethod to set an alternative name.

Let me check whether/how we can fix it.

ppalaga avatar Apr 10 '24 14:04 ppalaga

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 avatar Apr 10 '24 16:04 ppalaga

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.

ppalaga avatar Apr 10 '24 16:04 ppalaga