You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Alexander Ziubin (Jira)" <ji...@apache.org> on 2022/11/22 19:13:00 UTC
[jira] [Updated] (CXF-8796) IllegalArgumentException: argument type mismatch with code first RPC when parameter omitted
[ https://issues.apache.org/jira/browse/CXF-8796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Ziubin updated CXF-8796:
----------------------------------
Description:
When migrating legacy code-first RPC Web application from Axis to CXF, I found an issue with SOAP binding. CXF is passing MessageContentsList.REMOVED_MARKER instead of absent parameter producing "argument type mismatch while invoking ... with params ... java.lang.Object" response faultstring and "java.lang.IllegalArgumentException: argument type mismatch" message in the log.
{code:java}
@WebService(targetNamespace = "http://test.apache.org/")
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.RPC, use = javax.jws.soap.SOAPBinding.Use.LITERAL)
public class SoapBindingArgumentTypeMismatch {
public boolean allocate(Integer projectId,
Integer[] targetIds,
Integer[] parameterIds) {
return targetIds == null;
}
}{code}
Expected behavior of this sample Web service is to return true, when the targetIds parameter is absent in the SOAP request, but instead, CXF produces exception and fault response. Below is a sample SOAP request:
{code:xml}
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:test="http://test.apache.org/"
xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<test:allocate>
<arg0>1</arg0>
<arg2 xsi:type = "SOAP-ENC:Array" SOAP-ENC:arrayType = "xsd:int[1]">
<item>222</item>
</arg2>
</test:allocate>
</soapenv:Body>
</soapenv:Envelope>{code}
Everything else works as expected with CXF and this issue is the only blocker. I did some research and found that bean validation is also affected for both hibernate-validator and Apache bval bean validation providers.
I verified the behavior with CXF 3.5.2 and 3.5.4, but it seems that other versions have this issue too.
was:
When migrating legacy code-first RPC Web application from Axis to CXF, I found an issue with SOAP binding. CXF is passing MessageContentsList.REMOVED_MARKER instead of absent parameter producing "argument type mismatch while invoking ... with params ... java.lang.Object" response faultstring and "java.lang.IllegalArgumentException: argument type mismatch" message in the log.
{code:java}
@WebService(targetNamespace = "http://test.apache.org/")
@SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.RPC, use = javax.jws.soap.SOAPBinding.Use.LITERAL)
public class SoapBindingArgumentTypeMismatch {
public boolean allocate(Integer projectId,
Integer[] targetIds,
Integer[] parameterIds) {
return targetIds == null;
}
}{code}
Expected behavior of this sample Web service is to return true, when the targetIds parameter is absent in the SOAP request, but instead, CXF produces exception and fault response. Below is a sample SOAP request:
{code:xml}
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:test="http://test.apache.org/"
xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<test:allocate>
<arg0>1</arg0>
<arg2 xsi:type = "SOAP-ENC:Array" SOAP-ENC:arrayType = "xsd:int[1]">
<item>222</item>
</arg2>
</test:allocate>
</soapenv:Body>
</soapenv:Envelope>{code}
Everything else works as expected with CXF and this issue is the only blocker. I did some research and found that bean validation is also affected for both hibernate-validator and Apache bval bean validation providers.
I verified the behavior with CXF 3.5.2 and 3.5.4, but it seems that other versions have this issue too.
I am about to submit pull request with the fix.
> IllegalArgumentException: argument type mismatch with code first RPC when parameter omitted
> -------------------------------------------------------------------------------------------
>
> Key: CXF-8796
> URL: https://issues.apache.org/jira/browse/CXF-8796
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 3.5.4
> Reporter: Alexander Ziubin
> Priority: Major
> Attachments: RpcSoapBindingArgumentTypeMismatch.zip, allocate.xml
>
>
> When migrating legacy code-first RPC Web application from Axis to CXF, I found an issue with SOAP binding. CXF is passing MessageContentsList.REMOVED_MARKER instead of absent parameter producing "argument type mismatch while invoking ... with params ... java.lang.Object" response faultstring and "java.lang.IllegalArgumentException: argument type mismatch" message in the log.
> {code:java}
> @WebService(targetNamespace = "http://test.apache.org/")
> @SOAPBinding(style = javax.jws.soap.SOAPBinding.Style.RPC, use = javax.jws.soap.SOAPBinding.Use.LITERAL)
> public class SoapBindingArgumentTypeMismatch {
> public boolean allocate(Integer projectId,
> Integer[] targetIds,
> Integer[] parameterIds) {
> return targetIds == null;
> }
> }{code}
> Expected behavior of this sample Web service is to return true, when the targetIds parameter is absent in the SOAP request, but instead, CXF produces exception and fault response. Below is a sample SOAP request:
> {code:xml}
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:test="http://test.apache.org/"
> xmlns:SOAP-ENC = "http://schemas.xmlsoap.org/soap/encoding/"
> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance">
> <soapenv:Header/>
> <soapenv:Body>
> <test:allocate>
> <arg0>1</arg0>
> <arg2 xsi:type = "SOAP-ENC:Array" SOAP-ENC:arrayType = "xsd:int[1]">
> <item>222</item>
> </arg2>
> </test:allocate>
> </soapenv:Body>
> </soapenv:Envelope>{code}
> Everything else works as expected with CXF and this issue is the only blocker. I did some research and found that bean validation is also affected for both hibernate-validator and Apache bval bean validation providers.
> I verified the behavior with CXF 3.5.2 and 3.5.4, but it seems that other versions have this issue too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)