Petals BC SOAP

We are facing to AXIS2-4264.

As Petals BC Soap 4.3.x is based on Axis2 1.5.2, upgrading Axis2 version to 1.6 or upper is hazardous. As mentioned here we can easily disable SOAPAction.

So, for a maintenance release, we will introduce a new parameter at SU provide level to disable SOAPAction. And we will upgrade the Axis2 version in dev main line.

Caution, specific processing should be applied according to the SOAP version:

• SOAP 1.1, the HTTP header 'SOAPAction' is required. So, it will be set to an empty value if defined in WSDL as: <soap11:operation soapAction=""/> or if it is missing in WSDL,
• SOAP 1.2, the HTTP header 'SOAPAction' is optional. So, it will be absent if defined in WSDL as: <soap12:operation soapAction=""/> or if it is missing in WSDL.

AXIS2-4264 has been worked around in branch Petals ESB 4.3.x introducing a new parameter 'disable-soapaction' as mentioned below.

See svn#37549, svn#37550 and svn#37551

Reopened to be merged in trunk

There is something I don't understand:
If having no soapAction in the WSDL with Soap1.1 is forbidden, why do the integration tests have such cases? If it is missing in the WSDL, the WSDL is wrong, and that's all, no? Or is the idea to anyway "help" the user by allowing no soapAction in SOAP1.1 and transforming these to empty ones?

Hi Victor,
soap action is not missing but it's value is blank.
WSDL is valid regarding SOAPUI or CXF Codegen.

WSDL's come from commercial software.

Regards.

Hi,

This was more of a general question regarding how to cleanly fix the problem in our code and tests
I think that for your use case everything should be ok now with the released workaround.
The next version will be cleaner normally (for Petals 5), and if we can backport this clean solution to Petals 4.3 we will do it

I fixed PETALSBCSOAP-153 (for trunk/Petals 5) that upgrades Axis to 1.6.3 but it seems their bug (AXIS2-4264) is not completely fixed w.r.t. to our problem here.

I committed a different workaround than the one you committed, that doesn't need to change the SUs or anything, we should investigate if it would work also with Petals 4.3.

Ok, so after some tests, it seems that the following patch is valid for Petals 4.3 SOAP BC to fix the current issue (i.e. without having to modify the JBI description of the SU):

 
--- petals-bc-soap/src/main/java/org/ow2/petals/binding/soap/listener/outgoing/SOAPCaller.java	(révision 37557)
+++ petals-bc-soap/src/main/java/org/ow2/petals/binding/soap/listener/outgoing/SOAPCaller.java	(copie de travail)
@@ -514,6 +514,13 @@
                     final BindingOperation bo = b.getBindingOperation(exchange.getOperationName());
                     if (bo != null) {
                         soapAction = bo.getSoapAction();
+                        // See PETALSBCSOAP-151
+                        if (soapAction == null || soapAction.isEmpty()) {
+                            // it must contain the characters for an empty string, if not
+                            // org.apache.axis2.transport.http.CommonsHTTPTransportSender.findSOAPAction(MessageContext)
+                            // won't be happy with it!
+                            soapAction = "\"\"";
+                        }

We may release a new version (4.3.5 ?) for Petals 4.3 after discussing it between us.

Ok thank you.
Don't hesitate to inform us what is the recommanded component we have to use with our 4.3 version of petals (for now, the christophe's one is OK (and he gave us a fix quickly )

Regards.
F.scellos

Ok, Victor you can integrate your better fix in branch Petals 4.3. We will release a new version of the Petals BC SOAP

Merged in trunk