Re: [I] cxf-soap: after upgrade from Quarkus 3.0.3.Final to 3.2.4.Final @QuarkusTest and @QuarkusIntegrationTest tests not working any more [camel-quarkus]

["jochenr (via GitHub)" <gi...@apache.org>]

jochenr commented on issue #5218:
URL: https://github.com/apache/camel-quarkus/issues/5218#issuecomment-1751782453

   
   Hello @ppalaga ,
   
   I just want to update this issue by providing the findings we made (together with Red Hat Support):
   
   My reproducers actually show several issues:
   
   1.) CXF configuration issue with HTTPConduit
   
   
   ```
   		TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
                   public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                       return null;
                   }
   
                   public void checkClientTrusted(X509Certificate[] certs, String authType) {
                   }
   
                   public void checkServerTrusted(X509Certificate[] certs, String authType) {
                   }
   
               } };
   			
   
   
               TLSClientParameters tlsCP = new TLSClientParameters();
               tlsCP.setDisableCNCheck(true);
               tlsCP.setHostnameVerifier(new NoopHostnameVerifier());
              
   	// this is needed with new version
   	// is this just a workaround or does it make sense, if I set a "NoopHostnameVerifier" ?
               tlsCP.setTrustManagers(trustAllCerts);
   
               httpConduit.setTlsClientParameters(tlsCP);
   
   ```
   
   same for an CxfEndpoint as producer in Quarkus camel-cxf:
   
   ```			
   			CxfEnpoint mockToSapCxfProducer;
   			....
   
   			/* this is now need start*/
   			SSLContextParameters sslContextParameters = new SSLContextParameters();
   			TrustManagersParameters trustManagersParameters = new TrustManagersParameters();
   			trustManagersParameters.setTrustManager(trustAllCerts[0]);
   			sslContextParameters.setTrustManagers(trustManagersParameters);
   			/* this is now needs end*/
   			mockToSapCxfProducer.setSslContextParameters(sslContextParameters);
   			
   			mockToSapCxfProducer.setHostnameVerifier(new NoopHostnameVerifier());
   ```		
   
   
   2.) Order/place where to get the HTTPConduit	
   
   You have to get the HTTPConduit
   ```		
   			HTTPConduit httpConduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
   ```		
   AFTER putting ENDPOINT_ADDRESS_PROPERTY did not work in my real application.
   
   Otherwise the default Endpoint of the WSDL is used instead of the one provided with "requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY...."
   Then it's the same as the WS-RM Problem (see 3.)
   
   this works:
   ```
   		ContactWS port = service.getPort(ContactWS.class);
                   BindingProvider bp = (BindingProvider) port;
   		Map<String, Object> requestContext = bp.getRequestContext();
   		requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://myhost/mywebservice");
   		HTTPConduit httpConduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
   		//....do something with the conduit....like describes in 1.)
   ```
   		
   this DOES NOT work any more with new version:
   ```
   		ContactWS port = service.getPort(ContactWS.class);
                   BindingProvider bp = (BindingProvider) port;
   		HTTPConduit httpConduit = (HTTPConduit) ClientProxy.getClient(port).getConduit();
   		//....do something with the conduit....like describes in 1.)
   		Map<String, Object> requestContext = bp.getRequestContext();
   		requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://myhost/mywebservice");
   ```		
   	
   See here: https://github.com/jochenr/my-camel-quarkus-projects/blob/9d6f45be41eea419cf23cff99b62620eecdb7b75/camel-quarkus-cxf-soap-wssecurity/quarkus-root/src/test/java/de/jochenr/integration/contact/CxfClientSyncTest.java#L82
   		
   		
   3.) WS-RM /WS-ReliableMessabingis always using the default URL from the WSDL file.
   
   See:
   https://github.com/jochenr/my-camel-quarkus-projects/tree/main/camel-quarkus-cxf-soap-wsrm
   and my previous comment 		
   https://github.com/apache/camel-quarkus/issues/5218#issuecomment-1730918810
   and
   https://github.com/quarkiverse/quarkus-cxf/issues/1061
   
   
   You cannot override it with "requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://myhost/mywebservice");" in a client using jax-ws api.
   
   And you also cannot override it in an producer CxfEndpoint 
   ```
   CxfEnpoint mockToSapCxfProducer = new CxfProducerEndpointBuilder("https://myhost/mywebservice", context);
   ....
   ```
   
   https://github.com/jochenr/my-camel-quarkus-projects/blob/9d6f45be41eea419cf23cff99b62620eecdb7b75/camel-quarkus-cxf-soap-wsrm/quarkus-root/src/test/java/de/jochenr/integration/contact/ContactTest.java#L114
   calls a Rest endoint
   from there the camel route uses a CxfProducer to call the backend
   https://github.com/jochenr/my-camel-quarkus-projects/blob/9d6f45be41eea419cf23cff99b62620eecdb7b75/camel-quarkus-cxf-soap-wsrm/quarkus-root/src/main/java/de/jochenr/quarkus/integration/contact/route/AsyncRouteBuilder.java#L101
   
   
   
   
   4.) QuarkusTest doesn't show exceptions in the cases above, but is just hanging.
   This made finding the issues above quite hard....
   
   
   
   I think the root issues of 1.) - 3.) is inside Cxf and should be fixed there.
   
   Since my employer is Red Hat Customer we continue working on the issues using the Red Hat Support portal.
   We need all of this (and more) fixed before the next release of "Red Hat Build of Camel-Quarkus".
   
   Should  we leave this open until everything is fixed or should we close it, because we contiue to work on it with Red Hat Support?
   
   Regards,
   Jochen


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org