cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Godding Boye (JIRA)" <>
Subject [jira] [Created] (CXF-6598) java.lang.IndexOutOfBoundsException when processing response
Date Mon, 21 Sep 2015 12:56:04 GMT
Erik Godding Boye created CXF-6598:

             Summary: java.lang.IndexOutOfBoundsException when processing response
                 Key: CXF-6598
             Project: CXF
          Issue Type: Bug
    Affects Versions: 3.1.2, 2.7.17, 3.0.6, 2.7.12
            Reporter: Erik Godding Boye
            Priority: Minor

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):
Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
	at java.util.ArrayList.rangeCheck(
	at java.util.ArrayList.get(
	at org.apache.cxf.message.MessageContentsList.get(
	at org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
	at org.apache.cxf.endpoint.ClientImpl.onMessage(
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(
	at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(
	at org.apache.cxf.transport.AbstractConduit.close(
	at org.apache.cxf.transport.http.HTTPConduit.close(
	at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(

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.

This message was sent by Atlassian JIRA

View raw message