Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
akil-rails opened this issue Apr 1, 2024 · 3 comments
Open

Comments

@akil-rails
Copy link

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
Copy link
Contributor

ppalaga commented Apr 10, 2024

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
Copy link
Contributor

ppalaga commented Apr 10, 2024

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
Copy link
Contributor

ppalaga commented Apr 10, 2024

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 added a commit to ppalaga/quarkus-cxf that referenced this issue Apr 10, 2024
ppalaga added a commit to ppalaga/quarkus-cxf that referenced this issue Apr 10, 2024
ppalaga added a commit to ppalaga/quarkus-cxf that referenced this issue Apr 10, 2024
ppalaga added a commit that referenced this issue Apr 10, 2024
same-name sevice methods in the same Java package #1326
zhfeng pushed a commit to zhfeng/quarkus-cxf that referenced this issue May 27, 2024
JiriOndrusek pushed a commit that referenced this issue May 28, 2024
same-name sevice methods in the same Java package #1326
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants