Native image error: Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/ #238
Comments
|
I also tried adding the bus-extension.txt and wsdl.plugin.xml mentioned in #194 via resources-config.json , when you want to add resources in native image , but still the same error. |
|
it come from |
|
lead reflection on ExtensibilityElement to check. |
|
Hello , in my project i have a REST service that call a SOAP service and transform that response to another JSON model. In the cxf-codegen-plugin i have added some bindings. With extraarg -b. Even if i delete the extra arg the error is the same.
|
|
Hmmm. I have checked and found the issue. org.apache.cxf.wsdl.binding.AbstractWSDLBindingFactory other potential missing classes by diff between processor and https://github.com/apache/cxf/blob/75fb6bb56d82f72771a9ee6ecab5d36168303f51/distribution/src/main/release/samples/jaxws_graalvm/src/graalvm/client/reflect-config.json and removing bus-extensions.txt: com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl |
|
maybe I can clean up more the list. When I register for reflection a class, maybe interface and abstract class must not been declared. I am thinking to Bus class for example. I am not sure it is usefull to add it. |
|
@dinosath are you by any chance able to update the attached to reproduce the issue you are seeing? You can run |
|
any news here ? |
|
Hello , i tried finding a public wsdl that generates the same issue as mine , but was not able to find one. Sadly the wsdl i use in my case is proprietary , so i cannot share it. |
|
@dinosath for all we know, you may have an invalid WSDL, or one that CXF cannot handle ... it's difficult to help you without a reproducer; this also seems to be an edge case that hasn't been encountered by others yet. Are you able to put together a simple WSDL that's representative of your proprietary one? Hopefully the patch @dufoli puts in will address your issue, and you're able to test it for us, but we're essentially throwing darts in the dark here ... :) |
|
Yeah i know it is hard to address the issue without a project that reproduce the problem and is accessible. Truthfully i hoped others encountered the issue as well... The wsdl is ok because we already use plain cxf in our quarkus project. |
|
OK so we will add all class to reflection for native and if you can test the branch before merge it will be perfect. |
|
@dinosath can you test with version of branch issue238 ? |
|
I have just added binding |
|
Yes i can test it. It is the least i can do , since i can not provide a wsdl file. |
|
I tested it and the issue remains. |
@dinosath are you able to share a cleansed version of your pom.xml? |
|
Can you share interface or at least obfuscated signature of method |
|
@shumonsharif Hello , sadly i cannot share the pom.xml. But i am sure it is not an issue with my pom because in the cxf-238.zip project i replaced the hello.wsdl with mine and no other changes apart from the cxfclient interface. The issue persists for both 0.8 and 0.9.0-SNAPSHOT from branch issue238. |
|
@dufoli this is an obfuscated signature of the method i used from the interface that is generated from the cxf-codegen plugin |
|
@dufoli Also the interface that i inject as cxfclient obfuscated |
Thanks for clarifying @dinosath ... there's clearly something unique to your WSDL and/or supporting schemas that's not getting handled properly. The info we've gathered so far is quite limited, and not helpful enough to address this issue. My only suggestion is that you try modifying the hello.wsdl to see how it impacts things. Start simple with the working version of |
|
Also the below will provide additional logging details ... add to your quarkus.log.level=INFO
quarkus.log.category."org.apache.cxf".level=TRACE
quarkus.log.category."io.quarkiverse.cxf".level=TRACE |
Hello, i stumbled over the same problem, i ran your example on my Windows 10 machine with the given command. Next thing i did, is building the app with the property quarkus.native.container-build=true as a docker image and ran it. Same result. In the build log i can see several nullpointerexceptions, which i can't get my head around. |
|
Hi @comrt can you please try to add -Dquarkus.native.auto-service-loader-registration=true to your build and let us know the results? The NPEs can safely be ignored - they are logged as DEBUG statements by the extension. Also, just to note - you are using Java 16 (which is experimental) - please stick to the Quarkus compatible Java 11 version. |
|
@shumonsharif i switched to jvm11 and ran it with the parameter. It doesn't work, the native image cannot be built, it fails with:
Please see the full build log as attachement Then i added the parameter --allow-incomplete-classpath to the nativa build args, it runs the test but fails with: |
|
hello
you can test it on a sample project: to see the error:
|
|
same issue than #194 . It was supposed to be fixed but I guess we have to check if ressources is well merged in quarkus for windows or if we have special stuff for that ? because native on windows seems to use uberjar. |
|
hmmm maybe solution is to change https://github.com/quarkiverse/quarkus-cxf/pull/218/files |
|
@dufoli It appears uberjar is broken in general, even on Mac OS. I doubled checked the |
|
ohhhh noooo. Can you reopen on quarkus side and we will have to find a solution for that with quarkus team... |
|
@shumonsharif @dufoli Thank you very much again for your investigations |
|
@shumonsharif I open the issue. |
|
@dufoli I think the PR I just submitted should address these issues. @comrt Can you please help us test on Windows native once @dufoli merges the PR? @marcelbraghini if you can help test too, that'd be great! |
|
We just missed the quarkusio/quarkus#5677 PR |
|
let s close and reopen if do not worked. |
|
@shumonsharif sorry if i'm commenting on the closed issue, but i will test it with quarkus 2.0 and the master branch. |
|
@comrt no problem at all - and thanks once again for your help! We'll reopen the issue in case it's still not fixed. |
|
@shumonsharif and @dufoli
Great Work (y) |
|
@shumonsharif have you test on your side because I can close the quarkus bug |
|
@dufoli yes, tested, let's close the Quarkus bug, glad this issue is finally resolved! |
|
hello guys
but thanks so much for the help @dufoli @shumonsharif |
|
@marcelbraghini Thanks, only suggestion I have is that you try the Also, including the following links in case we need to refer to these later ... |
|
Oh, I get it, |
|
@shumonsharif maybe we can use NativeImageSystemPropertyBuildItem to set property or NativeImageConfigBuildItem but I guess first one is the best. wdyt ? |
|
@dufoli the warning only gets printed for uberjar mode, and not in native mode. So I don't believe |
I build a native image using with GRAALVM via docker. The build is successful , but when i try to run my application i get the following error
Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/In my project dependencies are quarkus-cxf version 0.8 and Quarkus version 1.13.5.Final.
I use the cxf-codegen-plugin v3.4.3 to generate source code from a given wsdl and inject the CXFClient
The text was updated successfully, but these errors were encountered: