cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CXF-6598) java.lang.IndexOutOfBoundsException when processing response
Date Fri, 24 Mar 2017 14:52:41 GMT

     [ https://issues.apache.org/jira/browse/CXF-6598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Kulp resolved CXF-6598.
------------------------------
       Resolution: Fixed
         Assignee: Daniel Kulp
    Fix Version/s: 3.1.11
                   3.0.13
                   3.2.0

> 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
>            Assignee: Daniel Kulp
>            Priority: Minor
>             Fix For: 3.2.0, 3.0.13, 3.1.11
>
>         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.15#6346)

Mime
View raw message