Cxf ws-rm tests coverage - JVM only

[JiriOndrusek]

fixes partially https://github.com/apache/camel-quarkus/issues/4689

This PR adds test coverage of cxf-ws-rm, which works only in the JVM mode. Native mode shows several issues:

1. SecureRanom created at build time at https://github.com/apache/santuario-xml-security-java/blob/main/src/main/java/org/apache/xml/security/stax/ext/XMLSecurityConstants.java#L53 (which could be probably changed in the 3rd project)
2. This method returns null, although it look like the initialization is correct https://github.com/korteke/java-opensaml/blob/master/opensaml-core/src/main/java/org/opensaml/core/config/ConfigurationService.java#L101

[jamesnetherton]

Doesn't have to be part of this PR but...

Maybe 1. could be fixed by initializing (or reinitializing) XMLSecurityConstants at runtime?

2. perhaps there is some build time service provider config needed for this?

[JiriOndrusek]

Doesn't have to be part of this PR but...

Maybe 1. could be fixed by initializing (or reinitializing) XMLSecurityConstants at runtime?

2. perhaps there is some build time service provider config needed for this?

Unfortunately I tried to solve both issues, but as I remember ad 1 - Setting SecureRandom to runtime init didn't help., because it was in conflict with something which is build time ad 2 - I missed the suggested config - will try it - thanks! (I tried to get rid of the code with substitutions but without a success)

[JiriOndrusek]

@ppalaga thanks for a lot of hints. I'll try to implement all of them. Do you have an idea, why I'm not hitting https://github.com/quarkiverse/quarkus-cxf/issues/627#issuecomment-1341205682 ?

[ppalaga]

Maybe 1. could be fixed by initializing (or reinitializing) XMLSecurityConstants at runtime?

That's already the case in https://github.com/quarkiverse/quarkus-xmlsec/blob/main/deployment/src/main/java/io/quarkiverse/xmlsec/deployment/XmlsecProcessor.java#L85

I'd vote for first tring to make the Random creation in XMLSecurityConstants lazy directly in santuario-xml-security-java - there is just one reading occurrence in the same class. It should be rather easy.

Otherwise, we may put a substitution to https://github.com/quarkiverse/quarkus-xmlsec

[ppalaga]

Do you have an idea, why I'm not hitting quarkiverse/quarkus-cxf#627 (comment) ?

The fact that we do not hit the issue here is a good news, isn't it? 8-)

But yes, it would be good to understand why.

I have noticed that you do not set RMStoreFeature (plus the derby database extension and config) as I did in https://github.com/quarkiverse/quarkus-cxf/pull/626/files . That may or may not make the difference. @ffang your opinion would be welcome!

Otherwise, perhaps it just works with Camel! Do you see anything like It is not possible to send out-of-band acknowledgments to the anonymous address. An acknowledgement will be piggybacked on the next response. in the log?

[ppalaga]

Otherwise, perhaps it just works with Camel! Do you see anything like It is not possible to send out-of-band acknowledgments to the anonymous address. An acknowledgement will be piggybacked on the next response. in the log?

Maybe there is some servlet container implementation smuggled in through depending on cxf-rt-ws-rm directly or in some other way? @ffang has shown that adding undertow solves the qcxf issue.

[JiriOndrusek]

I fixed majority of issues, there are several unfinished issues:

1. Use of seda. I have to find a proper way of using direct instead (with the current noWsrm test, undelivered message blocks direct -> some kind of timeout should fix that)
2. As I made the wsrm test more pranoid. 1 test is failing now. I encountered a similar issue (with missing decoupeling) as you did. Wsrm tests sends msg1, which is received, msg2 is lost, then msg1 is received again. After that msg2 is received. Problem is

sequence not set for outbound message, skipped acknowledgement request

. From the short cxf debugging it seems, that I have to configure something more, to fill sequence for RMOutInterceptor @ffang Do you know which configuration is missing? (common sense says that acknowledgement is not configured correctly, so send of the message is repeated even if it was delivered)

3. Native execution, I'll try to use suggestion from the above comments to solve native failure?

[JiriOndrusek]

Otherwise, perhaps it just works with Camel! Do you see anything like It is not possible to send out-of-band acknowledgments to the anonymous address. An acknowledgement will be piggybacked on the next response. in the log?

@ppalaga I see the same warning as you: (follows grep acknowled from my log)

2023-03-31 14:18:58,737 WARN  [org.apa.cxf.ws.rm.RMOutInterceptor] (executor-thread-2) sequence not set for outbound message, skipped acknowledgement request
2023-03-31 14:19:00,726 WARN  [org.apa.cxf.ws.rm.Proxy] (RMManager-Timer-76482793) It is not possible to send out-of-band acknowledgments to the anonymous address.
An acknowledgement will be piggybacked on the next response. 
2023-03-31 14:19:02,746 WARN  [org.apa.cxf.ws.rm.RMOutInterceptor] (executor-thread-2) sequence not set for outbound message, skipped acknowledgement request
2023-03-31 14:19:02,844 WARN  [org.apa.cxf.ws.rm.RMOutInterceptor] (executor-thread-2) sequence not set for outbound message, skipped acknowledgement request
2023-03-31 14:19:04,738 WARN  [org.apa.cxf.ws.rm.Proxy] (RMManager-Timer-76482793) It is not possible to send out-of-band acknowledgments to the anonymous address.
An acknowledgement will be piggybacked on the next response. 

[JiriOndrusek]

Do you see sequence not set for outbound message, skipped acknowledgement request in you PR?

[ppalaga]

Do you see sequence not set for outbound message, skipped acknowledgement request in you PR?

Yes, it is there. My log is attached here: https://github.com/quarkiverse/quarkus-cxf/issues/627#issue-1473515823

[ppalaga]

2. As I made the wsrm test more pranoid. 1 test is failing now.

OK, it is a bad news, that it is failing, but is a great news that we understand it a bit more :-D

I encountered a similar issue (with missing decoupeling) as you did. Wsrm tests sends msg1, which is received, msg2 is lost, then msg1 is received again. After that msg2 is received. Problem is

sequence not set for outbound message, skipped acknowledgement request

I think @ffang explained it here https://github.com/quarkiverse/quarkus-cxf/issues/627#issuecomment-1338172377

[JiriOndrusek]

Do you see sequence not set for outbound message, skipped acknowledgement request in you PR?

Yes, it is there. My log is attached here: quarkiverse/quarkus-cxf#627 (comment)

Thanks for the link! So it seems, that the acknowledgement does not work in both PRs. I briefly debugged cxf's RMOutInterceptor and will continue, because the "shorter" warning should be avoidable by some configuration. (at least it seems so)

[JiriOndrusek]

~@ppalaga Did you try using of decoupled_endpoint? I can use CxfConfigurer to execute similar code like in CSB (code), but I'm not sure how should I support that on vertx server (or i'm missing something here)~

--- edited ----

~With decoupled endpoint tests are successful, I'll update PR shortly to make it successful.~

Mistake on my side, my configuration of decoupled endpoint doesn't seem to have an effect.

[ffang]

ffang

Hi @JiriOndrusek @ppalaga ,

IMO, the correct way to address https://github.com/quarkiverse/quarkus-cxf/issues/627 is that we should be able to create ws-rm/addressing decoupled endpoint on they fly using VertxDestinationFactory, so the decoupled endpoint on the ws-rm client is still using the platform servlet/http implementation(vertx on Quarkus).

I have been working on it and made some progress, will add more comments later on.

[ffang]

PR sent on quarkus-cxf https://github.com/quarkiverse/quarkus-cxf/pull/835

[ffang]

Hi @JiriOndrusek ,

Could you please run your test here in camel-quarkus against my patch(https://github.com/quarkiverse/quarkus-cxf/pull/835) from quarkus-cxf to see if it addresses the issue?

Thanks! Freeman

[JiriOndrusek]

Hi @ffang , I tried this PR changes with quarkiverse-cxf with commit 6da272f1e30bfca24056c836b7c59934affc2aa6 The result is still the same - failure. Is there any configuration required for your change?

[ffang]

Hi @ffang , I tried this PR changes with quarkiverse-cxf with commit 6da272f1e30bfca24056c836b7c59934affc2aa6 The result is still the same - failure. Is there any configuration required for your change?

Hi @JiriOndrusek ,

Could you please clarify that the failure is native or JVM?

My fix in quarkus-cxf is to enable VertxDestination for the decoupled endpoint and so fix up the "piggybacked" WARN message from the log, it doesn't touch native thing.

Thanks! Freeman

[JiriOndrusek]

The failure is JVM only.

• I built quarkus-cxf based on tag 2.0.1 with cherry-picked commit 6da272f1e30bfca24056c836b7c59934affc2aa6

• I run test CxfSoapWsrmTest in JVM mode.

The result is the same failure as without fix.

[ERROR]   CxfSoapWsrmTest.testWSRM:66 1 expectation failed.
Response body doesn't match expectation.
Expected: "Hello wsrm2!"
  Actual: Hello wsrm1!

Here is the test scenario. I hope it is correct.

1. Send msg01
2. receive msg01
3. Send msg02 -> lost by MessageLossSimulator
4. receive msg02 (because of reliable messaging - the second attempt)

Failure is caused by the fact that message in the step 4 is msg01, Which was happening because RM does not acknowledge that the message msg01 is received therefore it is send for the second time

[ffang]

CxfSoapWsrmTest

Hi @JiriOndrusek ,

Thanks for the clarification!

I just pushed another commit to https://github.com/quarkiverse/quarkus-cxf/pull/835

Could you please re-run your test against the new commit also.

Also your testcase need some configuration to use the decoupled endpoint like

--- a/integration-test-groups/cxf-soap/cxf-soap-ws-rm/src/main/java/org/apache/camel/quarkus/component/cxf/soap/wsrm/it/CxfSoapWsrmRoutes.java
+++ b/integration-test-groups/cxf-soap/cxf-soap-ws-rm/src/main/java/org/apache/camel/quarkus/component/cxf/soap/wsrm/it/CxfSoapWsrmRoutes.java
@@ -26,8 +26,15 @@ import jakarta.inject.Inject;
 import jakarta.inject.Named;
 import org.apache.camel.Processor;
 import org.apache.camel.builder.RouteBuilder;
+import org.apache.camel.component.cxf.jaxws.CxfConfigurer;
 import org.apache.camel.component.cxf.jaxws.CxfEndpoint;
+import org.apache.cxf.endpoint.Client;
+import org.apache.cxf.endpoint.Server;
 import org.apache.cxf.ext.logging.LoggingFeature;
+import org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory;
+import org.apache.cxf.transport.http.HTTPConduit;
+import org.apache.cxf.transports.http.configuration.HTTPClientPolicy;
+import org.apache.cxf.ws.addressing.WSAContextUtils;
 import org.apache.cxf.ws.rm.manager.AcksPolicyType;
 import org.apache.cxf.ws.rm.manager.DestinationPolicyType;
 import org.apache.cxf.ws.rmp.v200502.RMAssertion;
@@ -91,7 +98,7 @@ public class CxfSoapWsrmRoutes extends RouteBuilder {
         cxfEndpoint.setAddress("/wsrm/RouterPort");
 
         addWsRmFeature(cxfEndpoint);
-
+        cxfEndpoint.setCxfConfigurer(new MyCxfConfigurer());
         return cxfEndpoint;
     }
 
@@ -185,4 +192,32 @@ public class CxfSoapWsrmRoutes extends RouteBuilder {
                 : config.getValue("quarkus.http.port", Integer.class);
         return String.format("http://localhost:%d", port);
     }
+
+    public class MyCxfConfigurer implements CxfConfigurer {
+
+        @Override
+        public void configure(AbstractWSDLBasedEndpointFactory factoryBean) {
+            // Do nothing here
+        }
+
+        @Override
+        public void configureClient(Client client) {
+
+            String decoupledEndpoint = "/wsrm/decoupled_endpoint";
+            HTTPConduit hc = (HTTPConduit) (client.getConduit());
+            HTTPClientPolicy cp = hc.getClient();
+            cp.setDecoupledEndpoint(decoupledEndpoint);
+            client.getBus().setProperty(WSAContextUtils.DECOUPLED_ENDPOINT_BASE_PROPERTY,
+                    getServerUrl()
+                            + "/soapservice");
+
+        }
+
+        @Override
+        public void configureServer(Server server) {
+            // Do nothing here
+
+        }
+
+    }

I changed this on your CQ4689-cxf-wsrm-coverage-backup branch, then I checked the log and decoupled-endpoint works using vertx destination, also the lost message got re-transmitted as expected(ws-rm works)

Let me know if you have any further questions.

Thanks! Freeman

[JiriOndrusek]

@ffang thanks for explanation and the second commit. I retested both changes + configuration change with this PR and it works correcty!

I updated PR and as soon as the cxf changes are merged and adapted by CQ, PR should pass.

[jamesnetherton]

Is there anything left to do here or are we good to merge?

There is a failure in cxf-soap-grouped.

[JiriOndrusek]

This can not be merged , the error in cxf-grouped is caused by this. We need to get this change into quarkiverse-cxf (https://github.com/quarkiverse/quarkus-cxf/pull/835) and the upgrade q-cxf in CQ to make this PR work

[ppalaga]

I have converted to draft, so that it does not awake too much attention

[JiriOndrusek]

This PR seems to be obsolete, as the reliable messaging is covered in quarkus-cxf project here.