quarkiverse / quarkus-cxf

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

Native image error: Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/ #238

Closed dinosath closed 3 years ago

dinosath commented 3 years ago

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

dinosath commented 3 years ago

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.

dufoli commented 3 years ago

it come from https://github.com/apache/cxf/blob/75fb6bb56d82f72771a9ee6ecab5d36168303f51/rt/frontend/simple/src/main/java/org/apache/cxf/frontend/AbstractWSDLBasedEndpointFactory.java but do you have the exception. Or enable debug to get it ? to have detail about why it throw exception.

dufoli commented 3 years ago

lead reflection on ExtensibilityElement to check. Can you detail your project and config and of course the url you are checking with body.

dinosath commented 3 years ago

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.

Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/ at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createBindingInfo(AbstractWSDLBasedEndpointFactory.java:361) at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpointInfo(AbstractWSDLBasedEndpointFactory.java:268) at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:146) at org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91) at org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:159) at org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142) at io.quarkiverse.cxf.CxfClientProducer.produceCxfClient(CxfClientProducer.java:121) at io.quarkiverse.cxf.CxfClientProducer.loadCxfClient(CxfClientProducer.java:58) at com.example.ws.client.order.OrderInterfaceCxfClientProducer.createService(OrderInterfaceCxfClientProducer.zig:39) at com.example.ws.client.order.OrderInterfaceCxfClientProducer_ProducerMethod_createService_ae24ce3702b11fedf88d08b28907a75d7b63d9ad_Bean.create(OrderInterfaceCxfClientProducer_ProducerMethod_createService_ae24ce3702b11fedf88d08b28907a75d7b63d9ad_Bean.zig:210) at com.example.ws.client.order.OrderInterfaceCxfClientProducer_ProducerMethod_createService_ae24ce3702b11fedf88d08b28907a75d7b63d9ad_Bean.get(OrderInterfaceCxfClientProducer_ProducerMethod_createService_ae24ce3702b11fedf88d08b28907a75d7b63d9ad_Bean.zig:240) at com.example.ws.client.order.OrderInterfaceCxfClientProducer_ProducerMethod_createService_ae24ce3702b11fedf88d08b28907a75d7b63d9ad_Bean.get(OrderInterfaceCxfClientProducer_ProducerMethod_createService_ae24ce3702b11fedf88d08b28907a75d7b63d9ad_Bean.zig:275) at io.quarkus.arc.impl.CurrentInjectionPointProvider.get(CurrentInjectionPointProvider.java:52) at com.example.soap.OrdersSoapClient_Bean.create(OrdersSoapClient_Bean.zig:245) ... 45 more Caused by: org.apache.cxf.BusException: No binding factory for namespace http://schemas.xmlsoap.org/wsdl/soap/ registered. at org.apache.cxf.bus.managers.BindingFactoryManagerImpl.getBindingFactory(BindingFactoryManagerImpl.java:93) at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createBindingInfo(AbstractWSDLBasedEndpointFactory.java:348) ... 58 more

dufoli commented 3 years ago

Hmmm. I have checked and found the issue. all binding factory must be loaded with field and method in reflection and I handle only one in bus-extensions.txt

org.apache.cxf.wsdl.binding.AbstractWSDLBindingFactory org.apache.cxf.binding.xml.XMLBindingFactory org.apache.cxf.binding.corba.CorbaBindingFactory org.apache.cxf.bindings.soap.SOAPBindingFactory org.apache.cxf.binding.soap.SoapBindingFactory => rt/bindings/soap/src/main/resources/META-INF/cxf/bus-extensions.txt so ok org.apache.cxf.binding.AbstractBindingFactory

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 com.sun.xml.bind.v2.runtime.property.ArrayElementLeafProperty com.sun.xml.bind.v2.runtime.property.ArrayElementNodeProperty com.sun.xml.bind.v2.runtime.property.ArrayReferenceNodeProperty com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty com.sun.xml.bind.v2.runtime.property.SingleMapNodeProperty com.sun.xml.bind.v2.runtime.property.SingleReferenceNodeProperty java.lang.invoke.MethodHandles$Lookup java.lang.management.ManagementFactory java.lang.management.RuntimeMXBean java.net.Authenticator java.nio.Bits java.nio.Buffer java.nio.DirectByteBuffer java.security.MessageDigestSpi java.security.SecureRandomParameters java.util.concurrent.Executor jdk.internal.misc.Unsafe org.apache.cxf.binding.AbstractBindingFactory org.apache.cxf.Bus org.apache.cxf.common.util.OpcodesProxy org.apache.cxf.endpoint.Client org.apache.cxf.endpoint.Client$Contexts org.apache.cxf.endpoint.ClientCallback org.apache.cxf.endpoint.ConduitSelector org.apache.cxf.endpoint.Endpoint org.apache.cxf.ext.logging.LoggingBusLifecycleListener org.apache.cxf.ext.logging.LoggingFactoryBeanListener org.apache.cxf.ext.logging.OldLoggingFactoryBeanListener org.apache.cxf.message.Message org.apache.cxf.transport.Conduit org.apache.cxf.transport.http.ReferencingAuthenticator org.apache.cxf.ws.addressing.wsdl.UsingAddressing org.apache.xml.resolver.CatalogManager org.w3c.dom.UserDataHandler sun.misc.Unsafe sun.nio.ch.SelectorImpl sun.security.provider.DRBG sun.security.provider.SHA sun.security.provider.SHA2$SHA256

dufoli commented 3 years ago

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.

shumonsharif commented 3 years ago

@dinosath are you by any chance able to update the attached to reproduce the issue you are seeing? quarkus-cxf-238.zip

You can run mvn clean verify -Dnative to execute the native integration test.

dufoli commented 3 years ago

any news here ? @shumonsharif else I can add all refelction build item class....

shumonsharif commented 3 years ago

Hey @dufoli sounds good to me ... I was hoping we could at least verify whether the changes fix the issues @dinosath is having ... but not sure if we can get a reproducer. So let's add the build item classes, and keep our fingers crossed!

dinosath commented 3 years ago

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.

shumonsharif commented 3 years ago

@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 ... :)

dinosath commented 3 years ago

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.

dufoli commented 3 years ago

OK so we will add all class to reflection for native and if you can test the branch before merge it will be perfect.

dufoli commented 3 years ago

@dinosath can you test with version of branch issue238 ?

dufoli commented 3 years ago

I have just added binding

dinosath commented 3 years ago

Yes i can test it. It is the least i can do , since i can not provide a wsdl file.

dinosath commented 3 years ago

I tested it and the issue remains.

shumonsharif commented 3 years ago

The wsdl is ok because we already use plain cxf in our quarkus project.

@dinosath are you able to share a cleansed version of your pom.xml?

dufoli commented 3 years ago

Can you share interface or at least obfuscated signature of method

dinosath commented 3 years ago

@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.

dinosath commented 3 years ago

@dufoli this is an obfuscated signature of the method i used from the interface that is generated from the cxf-codegen plugin @WebMethod(operationName = "GetCustomList", action = "http://sample.data.com/contract/v1/get-list") @Action(input = "http://sample.data.com/contract/v1/get-list", fault = {}) @WebResult(name = "GetCustomListResponseModel", targetNamespace = "http://sample.data.com/schema/custom/v1", partName = "CustomList") public GetCustomListResponseModel getCustomList( @WebParam(partName = "CustomCriteria", name = "GetCustomListRequestModel", targetNamespace = "http://sample.data.com/schema/custom/v1") GetCustomListRequestModel customCriteria, @WebParam(partName = "H1", name = "Header1", targetNamespace = "http://sample.data.com/contract/header/v1", header = true) Header1 h1, @WebParam(partName = "H2", name = "Header2", targetNamespace = "http://sample.data.com/contract/header/v1", header = true) Header2 h2 ) throws CustomFault;

dinosath commented 3 years ago

@dufoli Also the interface that i inject as cxfclient obfuscated @WebService(targetNamespace = "http://sample.data.com/contract/v1", name = "CustomInterface") @XmlSeeAlso({com.sample.data.schema.ObjectFactory.class, com.sample.data.contract.fault.v1.ObjectFactory.class, com.sample.dataschema.common.v1.ObjectFactory.class}) @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) public interface CustomInterface {}

shumonsharif commented 3 years ago

@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.

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 quarkus-cxf-238.zip, and copy over one operation at a time (from your WSDL) to it, until things break. Let us know how it goes.

shumonsharif commented 3 years ago

Also the below will provide additional logging details ... add to your application.properties ... let us know if you discover anything new!

quarkus.log.level=INFO
quarkus.log.category."org.apache.cxf".level=TRACE
quarkus.log.category."io.quarkiverse.cxf".level=TRACE
comrt commented 3 years ago

@dinosath are you by any chance able to update the attached to reproduce the issue you are seeing? quarkus-cxf-238.zip

You can run mvn clean verify -Dnative to execute the native integration test.

Hello, i stumbled over the same problem, i ran your example on my Windows 10 machine with the given command. Result is: Caused by: org.apache.cxf.BusException: No binding factory for namespace http://schemas.xmlsoap.org/wsdl/soap/ registered.

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. I attached the buildlog from the native build on windows - hope it helps somehow.

buildlog.txt

shumonsharif commented 3 years ago

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.

comrt commented 3 years ago

@shumonsharif i switched to jvm11 and ran it with the parameter. It doesn't work, the native image cannot be built, it fails with:

Error: Unsupported features in 4 methods Detailed message: Error: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved type during parsing: org.jvnet.mimepull.MIMEPart. To diagnose the issue you can use the --allow-incomplete-classpath option. The missing type is then reported at run time when it is accessed the first time. Trace: at parsing com.sun.xml.messaging.saaj.soap.AttachmentPartImpl$1.getContentType(AttachmentPartImpl.java:175) Call path from entry point to com.sun.xml.messaging.saaj.soap.AttachmentPartImpl$1.getContentType(): at com.sun.xml.messaging.saaj.soap.AttachmentPartImpl$1.getContentType(AttachmentPartImpl.java:175) at javax.activation.DataSourceDataContentHandler.writeTo(DataHandler.java:791) at javax.activation.DataHandler$1.run(DataHandler.java:249) at java.lang.Thread.run(Thread.java:834) at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:519) at com.oracle.svm.core.windows.WindowsJavaThreads.osThreadStartRoutine(WindowsJavaThreads.java:138) at com.oracle.svm.core.code.IsolateEnterStub.WindowsJavaThreads_osThreadStartRoutine_4bc03aa26f8cdfc97ebd54050e8ae4bce1023851(generated:0) Error: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved type during parsing: org.jvnet.mimepull.MIMEPart. To diagnose the issue you can use the --allow-incomplete-classpath option. The missing type is then reported at run time when it is accessed the first time.

Please see the full build log as attachement buildlog-2021-06-16.txt

Then i added the parameter --allow-incomplete-classpath to the nativa build args, it runs the test but fails with: ERROR: Failed to start application (with profile prod) java.lang.InstantiationException: Typeorg.jboss.resteasy.microprofile.config.FilterConfigSourceImplcan not be instantiated reflectively as it does not have a no-parameter constructor or the no-parameter constructor has not been added explicitly to the native image. at java.lang.Class.newInstance(DynamicHub.java:883) at org.jboss.resteasy.microprofile.config.BaseServletConfigSource.<init>(BaseServletConfigSource.java:23) at org.jboss.resteasy.microprofile.config.FilterConfigSource.<init>(FilterConfigSource.java:21) at java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:780) at java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:722) at java.util.ServiceLoader$3.next(ServiceLoader.java:1395) at io.smallrye.config.SmallRyeConfigBuilder.discoverSources(SmallRyeConfigBuilder.java:90) at io.smallrye.config.SmallRyeConfig.buildConfigSources(SmallRyeConfig.java:83) at io.smallrye.config.SmallRyeConfig.<init>(SmallRyeConfig.java:66) at io.smallrye.config.SmallRyeConfigBuilder.build(SmallRyeConfigBuilder.java:360) at io.quarkus.runtime.generated.Config.readConfig(Config.zig:1165) at io.quarkus.deployment.steps.RuntimeConfigSetup.deploy(RuntimeConfigSetup.zig:42) at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:345) at io.quarkus.runtime.Application.start(Application.java:90) at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:100) at io.quarkus.runtime.Quarkus.run(Quarkus.java:66) at io.quarkus.runtime.Quarkus.run(Quarkus.java:42) at io.quarkus.runtime.Quarkus.run(Quarkus.java:119) at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)

shumonsharif commented 3 years ago

@comrt Thank you - I believe we may have made some progress here, and identified a potential issue. @dufoli Do you have some thoughts on org.jvnet.mimepull.MIMEPart for reflection?

Regarding the following error, it seems to have popped up now and then (you can search the Quarkus issues), and is unrelated to this extension. ERROR: Failed to start application (with profile prod) java.lang.InstantiationException: Type org.jboss.resteasy.microprofile.config.FilterConfigSourceImpl can not be instantiated reflectively as it does not have a no-parameter constructor or the no-parameter constructor has not been added explicitly to the native image.

As a workaround, you may need to add a reflection-config.json file (there's an example you can refer to here): https://github.com/quarkiverse/quarkus-cxf/files/6444938/changes.zip

dufoli commented 3 years ago

maybe add reflection for javax.wsdl.extensions.mime.MIMEMultipartRelated and org.jvnet.mimepull.MIMEPart but not sure

because the function registerDeserializer / registerSerializer on javax.wsdl.extensions.ExtensionRegistry and createExtension will use newInstance method to create the instance so reflection must been done on it.

class to add: javax.wsdl.Types => duplicate to remove from the list without methods. javax.wsdl.extensions.mime.MIMEPart => already in missing: org.apache.cxf.databinding.source.mime.MimeAttribute org.apache.cxf.wsdl.JAXBExtensionHelper

on another side a strange thing is that org.jvnet.mimepull.MIMEPart is not the same than javax.wsdl.extensions.mime.MIMEPart this mimePart is not used in cxf... Where it come from ??? maybe depend of jdk used ?

shumonsharif commented 3 years ago

@dufoli I agree - org.jvnet.mimepull.MIMEPart should not be getting used by CXF, the library doesn't even appear in the dependency tree for me.

@comrt are you running the quarkus-cxf-238.zip as is, or did you add anything to it? Can you run mvn dependency:tree for us? Also, if you would please share your JDK details with java -version?

comrt commented 3 years ago

@shumonsharif i only added the additional args (--allow-incomplete-classpath), when suggested by the build output.

Here's the JDK i used: java -version openjdk version "11.0.10" 2021-01-19 OpenJDK Runtime Environment GraalVM CE 21.0.0.2 (build 11.0.10+8-jvmci-21.0-b06) OpenJDK 64-Bit Server VM GraalVM CE 21.0.0.2 (build 11.0.10+8-jvmci-21.0-b06, mixed mode, sharing) Dependencies dependencies.txt

shumonsharif commented 3 years ago

@dufoli You're right, I think the quarkus.native.auto-service-loader-registration=true flag is what resulted in the JDK loading its internal implementation, which in turn needs org.jvnet.mimepull.MIMEPart. So using that flag is not a good option for us.

@comrt Can you please try the attached quarkus-cxf-238.zip with mvn clean verify -Dnative? The main changes in this version include:

Added a reflection-config.json file containing:

Updated the resources-config.json to include: "pattern": "META-INF/services/.*"

It may still break, but hopefully we can gather some additional info.

comrt commented 3 years ago

@shumonsharif it breaks again at integration test phase with "Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/". buildlog-2021-06-016.txt

Did try mvn clean package -Pnative -Dquarkus.native.container-build=true as well and tested it manually via docker. Still the same issue.

shumonsharif commented 3 years ago

@comrt Thanks for your support with this issue - we are unable to reproduce the issue, so we'll need your help to continue troubleshooting! I'm running out of ideas here, though I'm thinking it could be JDK / GraalVM related.

Can you please try one more thing for us ...

Update your pom.xml with the line below, and then build with -Dquarkus.native.auto-service-loader-registration=true

<quarkus.native.additional-build-args>--report-unsupported-elements-at-runtime,--enable-url-protocols=jar,-H:ResourceConfigurationFiles=resources-config.json,-H:ReflectionConfigurationFiles=reflection-config.json,-H:ServiceLoaderFeatureExcludeServices=javax.xml.soap.MessageFactory,-H:ServiceLoaderFeatureExcludeServices=javax.xml.soap.SOAPFactory,-H:ServiceLoaderFeatureExcludeServices=javax.xml.soap.SAAJMetaFactory</quarkus.native.additional-build-args>
comrt commented 3 years ago

@shumonsharif welcome, no thanks needed, you're doing a great job with this project here.

tried it, still no luck... buildlog-2021-06-17.txt

i'm still curious, why it's not working with -Dquarkus.native.container-build=true and the supported docker files, does it work for you?

shumonsharif commented 3 years ago

@comrt I may be missing something here; how are you executing and running the unit tests for the docker generated binary? I am on Mac OS, the docker build generates a Linux binary that can't execute ... with error cannot execute binary file. Can you share some details on what you're running and the output?

shumonsharif commented 3 years ago

FWIW @comrt , I built the docker image manually, ran it, and initiated a request using the following curl:

curl -H "Content-Type: application/json" --data 'Shumon' http://localhost:8080/rest/hello

Everything worked fine as expected. I've attached all the commands and respective logs. Kindly let us know if you notice any differences from your results. 01-mvn-native.txt 02-docker-build.txt 03-docker-run-curl.txt

comrt commented 3 years ago

@shumonsharif i used mvn clean package -Pnative -Dquarkus.native.container-build=true, which doesn't execute the IT-Tests but still creates the binary. Then i used the same commands as you to push the binary to the docker and ran the created image.

I reproduced your steps: 01-mvn-native.txt 02-docker-build.txt 03-docker-run-curl.txt

What i can see is the following: [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Uber JAR strategy is used for native image source JAR generation on Windows. This is done for the time being to work around a current GraalVM limitation on Windows concerning the maximum command length (see https://github.com/oracle/graal/issues/238 7). does it influence the binary result?

comrt commented 3 years ago

@shumonsharif I will try to get my hands on a Mac OS or Linux system and test it there. Maybe it's just a Windows GraalVM Problem.

shumonsharif commented 3 years ago

@comrt The docker native build is not using Windows GraalVM - but would be great if you could try out a Mac OS or Linux system, curious what result you get. Just a random thought occurred to me - could it be related to locale settings?

Also, it seems the WARNING you posted is just for the source JAR? So I don't think it should impact the native binary.

comrt commented 3 years ago

@shumonsharif It works on my MacBook... mvn clean package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.native-image-xmx=12g mac-mvn-native.txt mac-docker-run-curl.txt Seems to have something to do with the environment.

shumonsharif commented 3 years ago

@comrt Thanks for confirming!! Definitely appears as though it may be environment related. A little bizarre though that the docker image build would behave differently ... that's unexpected!

comrt commented 3 years ago

Next thing i tried, is building the binary on WSL and ran it there, works. What i did next, is pushing the binary - built on WSL - into a docker image on Windows itself, works also.

Somehow the image gets build differently on Windows than any other OS. My suggestion is indeed the native image source JAR. Doesn't the binary get built on top of that? Take a look at the warnings: [INFO] [io.quarkiverse.cxf.deployment.QuarkusCxfProcessor] producing dedicated CXFClientInfo bean named 'com.learnwebservices.services.hello.HelloEndpoint' for SEI com.learnwebservices.services.hello.HelloEndpoint [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Uber JAR strategy is used for native image source JAR generation on Windows. This is done for the time being to work around a current GraalVM limitation on Windows concerning the maximum command length (see https://github.com/oracle/graal/issues/238 7). [INFO] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Building fat jar: D:\data\junk\quarkus-cxf-238-2\target\quarkus-cxf-238-1.0.0-SNAPSHOT-native-image-source-jar\quarkus-cxf-238-1.0.0-SNAPSHOT-runner.jar [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [jakarta.transaction:jakarta.transaction-api::jar:1.3.3(compile), org.apache.geronimo.specs:geronimo-jta_1.1_spec::jar:1.1.1(compile)] contain duplicate files, e.g. javax/transaction/UserT ransaction.class [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [com.sun.activation:jakarta.activation::jar:1.2.1(compile), jakarta.activation:jakarta.activation-api::jar:1.2.1(compile)] contain duplicate files, e.g. javax/activation/ActivationDataFlav or.class [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [org.apache.cxf:cxf-rt-frontend-simple::jar:3.4.3(compile), org.apache.cxf:cxf-rt-ws-policy::jar:3.4.3(compile), org.apache.cxf:cxf-core::jar:3.4.3(compile), org.apache.cxf:cxf-rt-ws-addr: :jar:3.4.3(compile), org.apache.cxf:cxf-rt-transports-http::jar:3.4.3(compile), org.apache.cxf:cxf-rt-bindings-soap::jar:3.4.3(compile), org.apache.cxf:cxf-rt-frontend-jaxws::jar:3.4.3(compile)] contain duplicate files, e.g. META-INF/spring.schemas [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [org.apache.cxf:cxf-rt-frontend-simple::jar:3.4.3(compile), org.apache.cxf:cxf-core::jar:3.4.3(compile), org.apache.cxf:cxf-rt-transports-http::jar:3.4.3(compile), org.apache.cxf:cxf-rt-fr ontend-jaxws::jar:3.4.3(compile)] contain duplicate files, e.g. META-INF/blueprint.handlers [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [org.apache.cxf:cxf-rt-bindings-xml::jar:3.4.3(compile), org.apache.cxf:cxf-rt-bindings-soap::jar:3.4.3(compile)] contain duplicate files, e.g. META-INF/wsdl.plugin.xml [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [org.apache.cxf:cxf-rt-frontend-simple::jar:3.4.3(compile), org.apache.cxf:cxf-rt-ws-policy::jar:3.4.3(compile), org.apache.cxf:cxf-core::jar:3.4.3(compile), org.apache.cxf:cxf-rt-ws-addr: :jar:3.4.3(compile), org.apache.cxf:cxf-rt-databinding-jaxb::jar:3.4.3(compile), org.apache.cxf:cxf-rt-bindings-xml::jar:3.4.3(compile), org.apache.cxf:cxf-rt-transports-http::jar:3.4.3(compile), org.apache.cxf:cxf-rt-bindings-soap::jar:3.4.3(compile), org.apache.cxf:cxf-rt-frontend-jaxws::jar:3.4.3(compile), o rg.apache.cxf:cxf-rt-wsdl::jar:3.4.3(compile)] contain duplicate files, e.g. META-INF/cxf/bus-extensions.txt [WARNING] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Dependencies with duplicate files detected. The dependencies [org.apache.cxf:cxf-rt-frontend-simple::jar:3.4.3(compile), org.apache.cxf:cxf-rt-databinding-jaxb::jar:3.4.3(compile)] contain duplicate files, e.g. org/apache/cxf/endpoint/dynamic/simple -binding.xjb

shumonsharif commented 3 years ago

Awesome, thanks @comrt for the additional testing, and I think you're right, the native sources are likely being used to create the native binary. I tried looking into the referenced GraalVM #2387 and Quarkus #8860 issues, but couldn't figure out whether the fixes were ever addressed properly. Will try to dig in some more later today ...

dufoli commented 3 years ago

I think we can open a bug on graalvm

shumonsharif commented 3 years ago

@dufoli @comrt As I understood it, the issue for GraalVM #2387 was already fixed. I believe the core issue is that the Quarkus changes to address the original GraalVM Windows limitation needs to be reverted, as per:

https://github.com/quarkusio/quarkus/pull/8860/files#diff-e2e9394cec5c2edcecfcc2ee65fd6bedb2727a87b2864fa4d736bc4725d96569R635

marcelbraghini commented 3 years ago

hello i'm facing a similar problem, only occurs when I run the service from the jar (uber jar), when I go up with quarkus:dev it works perfectly

Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/

you can test it on a sample project: https://github.com/marcelbraghini/integrations

to see the error: java -jar target/integrations-0.1.0-SNAPSHOT-runner.jar

curl --location --request GET 'localhost:8080/v1/endereco/89805350'

dufoli commented 3 years ago

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.

dufoli commented 3 years ago

hmmm maybe solution is to change https://github.com/quarkiverse/quarkus-cxf/pull/218/files by adding in test if windows && native same behaviour than uberjar to merge files in order to have because as @shumonsharif provide link, the native on windows seems to use uberjar... but if we do so we need to check if patch done on quarkus to use merged ressource work in native mode.

https://github.com/quarkusio/quarkus/pull/8860/files#diff-e2e9394cec5c2edcecfcc2ee65fd6bedb2727a87b2864fa4d736bc4725d96569R635

shumonsharif commented 3 years ago

@dufoli It appears uberjar is broken in general, even on Mac OS. I doubled checked the META-INF/cxf/bus-extensions.txt and the META-INF/wsdl.plugin.xml files generated in @marcelbraghini 's projects uberjar - both files are getting merged properly and placed in the correct locations, but failing at runtime with Could not resolve a binding for http://schemas.xmlsoap.org/wsdl/soap/. I would suggest we either reopen #194 or create a new issue to address uberjar.