[
https://issues.apache.org/jira/browse/CXF-6598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Godding Boye updated CXF-6598:
-----------------------------------
Description:
We are trying to upgrade to a newer version of CXF in a web service client
application. Most of our services are running fine on the new version, but one
of the services are failing consequently with the following exception (line
numbers depending a bit on CXF version tested):
{noformat}
Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at
org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
at
org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(HolderInInterceptor.java:69)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1644)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1532)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:652)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
{noformat}
I have tried to pinpoint exactly where this error originates from, but this
seems to be "buried" deep into the implementation details. I would have loved
to submit a pull request, but I suspect any suggested change from my part would
cause other things to fail.
However, I can try to summarize my findings, so someone with knowledge of the
CXF source code hopefully can dig deeper into this:
- I seems to me that the problem is related to the fact that the
cxf-codegen-plugin consider the operation to have one *in-out parameter*, and
not one in and one out parameter. I do not understand why, but maybe someone
with deeper understanding of WSDLs can explain?
- The problem also seems to be related to the fact that we prefer *WRAPPED
mode* over BARE mode. If I configure the cxf-codegen-plugin to generate BARE
mode Java stubs, it all works. Changing to BARE mode for this particular
service seems to be the only workaround I can think of; without changing the
WSDL.
- The problem also has something to do with the use of *implicit soap
(response) header* in the WSDL. If I remove the implicit soap header from the
WSDL, everything works fine.
I have attached a zip-file containing the WSDL in question (simplified and
anonymized) and a failing test case. The test case is inspired by the system
tests in cxf-systests-uncategorized, and may be added to this module when/if
the bug is fixed.
Note: The WSDL may seem a bit strange (I did not make it), but it appears to be
valid (at least SoapUI says it is). We are just implementing a client
application to a legacy system, so changing the WSDL is not an option (unless
proved invalid....)
I have tested a few different versions of CXF, and the problem seems to have
appeared in version 2.7.12 (works with 2.7.11). I am not sure what changes that
may have caused this to break, but I suspect changes related to CXF-5676. This
particular issue is the only one in 2.7.12 (that I could find) related to
implicit SOAP headers.
was:
We are trying to upgrade to a newer version of CXF in a web service client
application. Most of our services are running fine on the new version, but one
of the services are failing consequently with the following exception (line
numbers depending a bit on CXF version tested):
{noformat}
Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at
org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
at
org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(HolderInInterceptor.java:69)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1644)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1532)
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:652)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
{noformat}
I have tried to pinpoint exactly where this error originates from, but this
seems to be "buried" deep into the implementation details. I would have loved
to submit a pull request, but I suspect any suggested change from my part would
cause other things to fail.
However, I can try to summarize my findings, so someone with knowledge of the
CXF source code hopefully can dig deeper into this:
- I seems to me that the problem is related to the fact that the
cxf-codegen-plugin consider the operation to have one *in-out parameter*, and
not one in and one out parameter. I do not understand why, but maybe someone
with deeper understanding of WSDLs can explain?
- The problem also seems to be related to the fact that we prefer *BARE mode*
over WRAPPED mode. If I configure the cxf-codegen-plugin to generate WRAPPED
mode Java stubs, it all works. Changing to WRAPPED mode for this particular
service seems to be the only workaround I can think of; without changing the
WSDL.
- The problem also has something to do with the use of *implicit soap
(response) header* in the WSDL. If I remove the implicit soap header from the
WSDL, everything works fine.
I have attached a zip-file containing the WSDL in question (simplified and
anonymized) and a failing test case. The test case is inspired by the system
tests in cxf-systests-uncategorized, and may be added to this module when/if
the bug is fixed.
Note: The WSDL may seem a bit strange (I did not make it), but it appears to be
valid (at least SoapUI says it is). We are just implementing a client
application to a legacy system, so changing the WSDL is not an option (unless
proved invalid....)
I have tested a few different versions of CXF, and the problem seems to have
appeared in version 2.7.12 (works with 2.7.11). I am not sure what changes that
may have caused this to break, but I suspect changes related to CXF-5676. This
particular issue is the only one in 2.7.12 (that I could find) related to
implicit SOAP headers.
> java.lang.IndexOutOfBoundsException when processing response
> ------------------------------------------------------------
>
> Key: CXF-6598
> URL: https://issues.apache.org/jira/browse/CXF-6598
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.7.12, 3.0.6, 2.7.17, 3.1.2
> Reporter: Erik Godding Boye
> Priority: Minor
> Attachments: testcase.zip
>
>
> We are trying to upgrade to a newer version of CXF in a web service client
> application. Most of our services are running fine on the new version, but
> one of the services are failing consequently with the following exception
> (line numbers depending a bit on CXF version tested):
> {noformat}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:653)
> at java.util.ArrayList.get(ArrayList.java:429)
> at
> org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
> at
> org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(HolderInInterceptor.java:69)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:802)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1644)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1532)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1330)
> at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:652)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> {noformat}
> I have tried to pinpoint exactly where this error originates from, but this
> seems to be "buried" deep into the implementation details. I would have loved
> to submit a pull request, but I suspect any suggested change from my part
> would cause other things to fail.
> However, I can try to summarize my findings, so someone with knowledge of the
> CXF source code hopefully can dig deeper into this:
> - I seems to me that the problem is related to the fact that the
> cxf-codegen-plugin consider the operation to have one *in-out parameter*, and
> not one in and one out parameter. I do not understand why, but maybe someone
> with deeper understanding of WSDLs can explain?
> - The problem also seems to be related to the fact that we prefer *WRAPPED
> mode* over BARE mode. If I configure the cxf-codegen-plugin to generate BARE
> mode Java stubs, it all works. Changing to BARE mode for this particular
> service seems to be the only workaround I can think of; without changing the
> WSDL.
> - The problem also has something to do with the use of *implicit soap
> (response) header* in the WSDL. If I remove the implicit soap header from the
> WSDL, everything works fine.
> I have attached a zip-file containing the WSDL in question (simplified and
> anonymized) and a failing test case. The test case is inspired by the system
> tests in cxf-systests-uncategorized, and may be added to this module when/if
> the bug is fixed.
> Note: The WSDL may seem a bit strange (I did not make it), but it appears to
> be valid (at least SoapUI says it is). We are just implementing a client
> application to a legacy system, so changing the WSDL is not an option (unless
> proved invalid....)
> I have tested a few different versions of CXF, and the problem seems to have
> appeared in version 2.7.12 (works with 2.7.11). I am not sure what changes
> that may have caused this to break, but I suspect changes related to
> CXF-5676. This particular issue is the only one in 2.7.12 (that I could find)
> related to implicit SOAP headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
