Yes, I found that exactly. If I patch CXF to not complain about the
ArrayList size(), then CXF passes what should be the 19th parameter (a
Holder) as the 16th parameter, violating typing at runtime. It seems like
certain parts are simply missing. Every call does have a mix of headers,
in-params, and out-holders.
The WSDL is technically invalid. They define multiple methods with the
same body type, which strictly speaking is illegal. There may be other
problems as well, but the validation seems to stop after the 1st error.
Our partner is a large international corporation presumably using .NET,
and any comment like "your WSDL is invalid" will be roundly met with
silence.
I tried Axis2 on the WSDL but due to the size of the WSDL/XSD's, Axis
generated a method which is too big for javac ("code too large," meaning
the compiled method is larger than 65535 bytes of JVM opcode). It also
generated a source file too large for my IDE's editor, which is highly
annoying when you have hundreds of types and no code completion.
Honestly, after losing more than a week on this, I'm just POSTing an XML
template and using XPath to parse the response. A week of zero net work is
crushing for a startup, and I just cannot spend any more time on this.
Sorry I can't identify our partner or give you any samples.
On Wed, Jun 19, 2013 at 1:20 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> 19 parameters?!?!? Jeesh… I think I'd be strongly considering running
> wsdl2java with the -bareMethods parameters to flip to bare mode.
> Seriously, consider it.
>
> We'd likely need a test case for this. When you are getting that many
> parameters, there is definitely some possibilities of getting some ordering
> mixed up, particularly if there is a mix of headers and non-headers and
> in/outs, etc….
>
> Dan
>
>
>
> On Jun 17, 2013, at 8:13 PM, Tim Olson <kash...@gmail.com> wrote:
>
> > Our CXF client consistently gets an IndexOutOfBoundsException
> > (java.lang.IndexOutOfBoundsException:
> > Index: 19, Size: 19) when handling a SOAP response which otherwise looks
> > valid. We're using CXF 2.7.5 with the wsdl2java Maven plugin to generate
> > client wrapper code.
> >
> > The stack trace goes from
> > HolderInInterceptor:69<
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.5/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/interceptors/HolderInInterceptor.java
> >
> >
> > if (client) {
> > List<Holder<?>> outHolders =
> > CastUtils.cast((List<?>)message.getExchange()
> > .getOutMessage().get(CLIENT_HOLDERS));
> > for (MessagePartInfo part : parts) {
> > if (part.getIndex() != 0 && part.getTypeClass() != null) {
> > @SuppressWarnings("unchecked")
> > Holder<Object> holder =
> > (Holder<Object>)outHolders.get(part.getIndex() - 1);
> > if (holder != null) {*
> > holder.value = inObjects.get(part);*
> > inObjects.put(part, holder);
> > }
> > }
> > }
> > }
> >
> >
> > to MessageContentsList:80<
> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.7.5/api/src/main/java/org/apache/cxf/message/MessageContentsList.java
> >
> >
> > public Object get(MessagePartInfo key) {
> > Object o = *super.get(key.getIndex())*;
> > return o == REMOVED_MARKER ? null : o;
> > }
> >
> >
> > and then
> > java.lang.IndexOutOfBoundsException: Index: 19, Size: 19
> > at java.util.ArrayList.RangeCheck(ArrayList.java:547)
> > at java.util.ArrayList.get(ArrayList.java:322)
> > at
> >
> org.apache.cxf.message.MessageContentsList.get(MessageContentsList.java:80)
> > at
> >
> org.apache.cxf.jaxws.interceptors.HolderInInterceptor.handleMessage(HolderInInterceptor.java:69)
> > ...
> >
> > In other areas of the code, the MessagePartInfo indices seem to be
> > converted from 1-based indices to 0-based, but that's not happening here.
> > Should the line in MessageContentsList be changed to *
> > super.get(key.getIndex()-1)*? Otherwise, I am at a loss for debugging
> this
> > further.
> >
> > Unfortunately, I can't share the WSDL or SOAP, since our partner
> considers
> > it proprietary, but I can try to offer generic answers to any questions.
> > The WSDL they give us is *massive* and not easy to boil down into a small
> > test case (about 100 XSD's, many complex types).
> >
> >
> > Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Index:
> 19,
> > Size: 19
> > at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:155)
> > *[elided]*
> > Caused by: java.lang.IndexOutOfBoundsException: Index: 19, Size: 19
> > at java.util.ArrayList.RangeCheck(ArrayList.java:547)
> > at java.util.ArrayList.get(ArrayList.java:322)
> > 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:271)
> > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:800)
> > at
> >
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1592)
> > at
> >
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1490)
> > at
> >
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1309)
> > at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:622)
> > at
> >
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> > at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
> > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
> > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
> > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
> > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
> > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> > at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:133)
> > ... 10 more
> >
> >
> > Thanks for any ideas,
> > Tim
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
