You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Christopher Moesel <Ch...@avid.com> on 2007/11/15 22:49:18 UTC
CXF 2.0.3 Introduces "wrong number of arguments" fault?
Hello,
I am using CXF with my JAX-WS WSDL-first web service. My schema
specifies a mandatory custom credentials element in the SOAP header.
With CXF 2.0.2, if the client sent a request that was missing that
custom credentials element in the header, it would come into the
implementation code as null. This was good, because I could handle it
as I wanted to from there.
With CXF 2.0.3, it never even makes it to my implementation code.
Instead, a soap:server fault is automatically sent back to the client.
The message of the fault says:
wrong number of arguments while invoking public
com.mycompany.MyOperationResponseType
com.mycompany.MyWebServiceImpl.myOperation(com.mycompany.MyOperationType
,com.mycompany.UserCredentialsType) throws com.mycompany.MyFault with
params [com.mycompany.MyOperationType@e345c2].
I'd really like to have control over this-I actually prefer not to send
back a fault, but rather to respond in a different way. In addition, if
I *did* want to send back a fault, I wouldn't want the fault message to
contain my class names-and I would probably want to return my custom
fault type in the fault details as well.
Is this by design, or is this a regression? Is anyone aware of a
workaround for this?
I have also pasted the stacktrace below. Thanks for your help!
-Chris
Nov 15, 2007 4:34:58 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: wrong number of arguments while
invoking public com
.mycompany.MyOperationResponseType com.mycompany.MyWebServiceImpl.myOpe
ration(com.mycompany.MyOperationType,com.mycompany.UserCredentialsType)
thro
ws com.mycompany.MyFault with params
[com.mycompany.MyOperationType@e345c2].
at
org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractIn
voker.java:109)
at
org.apache.cxf.jaxws.JAXWSMethodInvoker.createFault(JAXWSMethodInvoke
r.java:76)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
.java:101)
at
org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.jav
a:100)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
.java:68)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInv
okerInterceptor.java:56)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecu
tor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Se
rviceInvokerInterceptor.java:92)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
orChain.java:207)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainIniti
ationObserver.java:73)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(Servlet
Destination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(
ServletController.java:256)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletCont
roller.java:160)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCX
FServlet.java:170)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCX
FServlet.java:148)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491
)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
67)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:185)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
81)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
89)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
lerCollection.java:146)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
39)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:45
7)
at
org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
n.java:765)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
va:329)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
.java:475)
Caused by: java.lang.IllegalArgumentException: wrong number of arguments
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Abst
ractInvoker.java:124)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
.java:82)
... 31 more
Re: CXF 2.0.3 Introduces "wrong number of arguments" fault?
Posted by Daniel Kulp <dk...@apache.org>.
Dan,
I deployed new snapshots for both 2.0.4 and 2.1 on Friday. The fix
should be in both of them.
Dan
On Sunday 25 November 2007, Dan Connelly wrote:
> dan
>
> Did you fix get committed? What snapshot(s) have the fix?
>
> -- Dan Connelly
>
>
> Daniel Kulp wrote:
> Christopher,
>
> I don't think it was "intentional". It's probably a sideaffect of
> some of the cleanup we did around getting the out of band headers to
> actually work. Looking at the code and stuff, it probably would
> work if the header parameter wasn't the last one. When reading the
> body part in, the array would be updated with null for the the params
> before the body part.
>
> The other workaround would involve writing an itnerceptor to grep the
> param list and check the length and stuff. Not exactly fun.
>
> In anycase, I can reproduce it and I'm working on a fix now. However,
> I'm on a plane coming back from ApacheCon and I'm heading on vacation
> (with very limitted connectivity) tomorrow so I'm not sure when I'll
> get it committed. (or even when I'll get this email sent)
>
> Dan
>
>
> On Thursday 15 November 2007, Christopher Moesel wrote:
>
> Hello,
>
>
>
> I am using CXF with my JAX-WS WSDL-first web service. My schema
> specifies a mandatory custom credentials element in the SOAP header.
>
>
>
> With CXF 2.0.2, if the client sent a request that was missing that
> custom credentials element in the header, it would come into the
> implementation code as null. This was good, because I could handle it
> as I wanted to from there.
>
>
>
> With CXF 2.0.3, it never even makes it to my implementation code.
> Instead, a soap:server fault is automatically sent back to the client.
> The message of the fault says:
>
>
>
> wrong number of arguments while invoking public
> com.mycompany.MyOperationResponseType
> com.mycompany.MyWebServiceImpl.myOperation(com.mycompany.MyOperationTy
> pe ,com.mycompany.UserCredentialsType) throws com.mycompany.MyFault
> with params [com.mycompany.MyOperationType@e345c2].
>
>
>
> I'd really like to have control over this-I actually prefer not to
> send back a fault, but rather to respond in a different way. In
> addition, if I *did* want to send back a fault, I wouldn't want the
> fault message to contain my class names-and I would probably want to
> return my custom fault type in the fault details as well.
>
>
>
> Is this by design, or is this a regression? Is anyone aware of a
> workaround for this?
>
>
>
> I have also pasted the stacktrace below. Thanks for your help!
>
>
>
> -Chris
>
>
>
> Nov 15, 2007 4:34:58 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
>
> INFO: Interceptor has thrown exception, unwinding now
>
> org.apache.cxf.interceptor.Fault: wrong number of arguments while
> invoking public com
>
> .mycompany.MyOperationResponseType
> com.mycompany.MyWebServiceImpl.myOpe
>
> ration(com.mycompany.MyOperationType,com.mycompany.UserCredentialsType
> ) thro
>
> ws com.mycompany.MyFault with params
> [com.mycompany.MyOperationType@e345c2].
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractIn
>
> voker.java:109)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.createFault(JAXWSMethodInvoke
>
> r.java:76)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:101)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.jav
>
> a:100)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:68)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInv
>
> okerInterceptor.java:56)
>
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecu
>
> tor.java:37)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Se
>
> rviceInvokerInterceptor.java:92)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>
> orChain.java:207)
>
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainIniti
>
> ationObserver.java:73)
>
> at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(Servlet
>
> Destination.java:79)
>
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(
>
> ServletController.java:256)
>
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletCont
>
> roller.java:160)
>
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCX
>
> FServlet.java:170)
>
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCX
>
> FServlet.java:148)
>
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491
>
> )
>
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
>
> 67)
>
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
>
> a:185)
>
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
>
> 81)
>
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
>
> 89)
>
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
>
>
>
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
>
> lerCollection.java:146)
>
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
>
> java:114)
>
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
>
> 39)
>
> at org.mortbay.jetty.Server.handle(Server.java:285)
>
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:45
>
> 7)
>
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
>
> n.java:765)
>
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
>
> at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
>
> at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
>
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
>
> va:329)
>
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
>
> .java:475)
>
> Caused by: java.lang.IllegalArgumentException: wrong number of
> arguments
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>
> java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>
> sorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Abst
>
> ractInvoker.java:124)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:82)
>
> ... 31 more
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: CXF 2.0.3 Introduces "wrong number of arguments" fault?
Posted by Christopher Moesel <Ch...@avid.com>.
Dan--
Thanks for taking the time to look into this, and thank you for the
suggestions on workarounds. There is nothing in 2.0.3 that I need at
this point, so I will probably stick to 2.0.2 for now and wait to see if
it's adressed in 2.0.4.
Thanks again!
Chris
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, November 16, 2007 8:18 PM
To: cxf-user@incubator.apache.org
Cc: Christopher Moesel
Subject: Re: CXF 2.0.3 Introduces "wrong number of arguments" fault?
Christopher,
I don't think it was "intentional". It's probably a sideaffect of some
of the cleanup we did around getting the out of band headers to actually
work. Looking at the code and stuff, it probably would work if the
header parameter wasn't the last one. When reading the body part in,
the array would be updated with null for the the params before the body
part.
The other workaround would involve writing an itnerceptor to grep the
param list and check the length and stuff. Not exactly fun.
In anycase, I can reproduce it and I'm working on a fix now. However,
I'm on a plane coming back from ApacheCon and I'm heading on vacation
(with very limitted connectivity) tomorrow so I'm not sure when I'll get
it committed. (or even when I'll get this email sent)
Dan
On Thursday 15 November 2007, Christopher Moesel wrote:
> Hello,
>
>
>
> I am using CXF with my JAX-WS WSDL-first web service. My schema
> specifies a mandatory custom credentials element in the SOAP header.
>
>
>
> With CXF 2.0.2, if the client sent a request that was missing that
> custom credentials element in the header, it would come into the
> implementation code as null. This was good, because I could handle it
> as I wanted to from there.
>
>
>
> With CXF 2.0.3, it never even makes it to my implementation code.
> Instead, a soap:server fault is automatically sent back to the client.
> The message of the fault says:
>
>
>
> wrong number of arguments while invoking public
>com.mycompany.MyOperationResponseType
> com.mycompany.MyWebServiceImpl.myOperation(com.mycompany.MyOperationTy
>pe ,com.mycompany.UserCredentialsType) throws com.mycompany.MyFault
>with params [com.mycompany.MyOperationType@e345c2].
>
>
>
> I'd really like to have control over this-I actually prefer not to
> send back a fault, but rather to respond in a different way. In
> addition, if I *did* want to send back a fault, I wouldn't want the
> fault message to contain my class names-and I would probably want to
> return my custom fault type in the fault details as well.
>
>
>
> Is this by design, or is this a regression? Is anyone aware of a
> workaround for this?
>
>
>
> I have also pasted the stacktrace below. Thanks for your help!
>
>
>
> -Chris
>
>
>
> Nov 15, 2007 4:34:58 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
>
> INFO: Interceptor has thrown exception, unwinding now
>
> org.apache.cxf.interceptor.Fault: wrong number of arguments while
> invoking public com
>
> .mycompany.MyOperationResponseType
> com.mycompany.MyWebServiceImpl.myOpe
>
> ration(com.mycompany.MyOperationType,com.mycompany.UserCredentialsType
>) thro
>
> ws com.mycompany.MyFault with params
> [com.mycompany.MyOperationType@e345c2].
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractIn
>
> voker.java:109)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.createFault(JAXWSMethodInvoke
>
> r.java:76)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:101)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.jav
>
> a:100)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:68)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInv
>
> okerInterceptor.java:56)
>
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecu
>
> tor.java:37)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Se
>
> rviceInvokerInterceptor.java:92)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>
> orChain.java:207)
>
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainIniti
>
> ationObserver.java:73)
>
> at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(Servlet
>
> Destination.java:79)
>
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(
>
> ServletController.java:256)
>
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletCont
>
> roller.java:160)
>
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCX
>
> FServlet.java:170)
>
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCX
>
> FServlet.java:148)
>
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491
>
> )
>
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
>
> 67)
>
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
>
> a:185)
>
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
>
> 81)
>
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
>
> 89)
>
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
>
>
>
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
>
> lerCollection.java:146)
>
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
>
> java:114)
>
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
>
> 39)
>
> at org.mortbay.jetty.Server.handle(Server.java:285)
>
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:45
>
> 7)
>
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
>
> n.java:765)
>
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
>
> at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
>
> at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
>
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
>
> va:329)
>
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
>
> .java:475)
>
> Caused by: java.lang.IllegalArgumentException: wrong number of
> arguments
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>
> java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>
> sorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Abst
>
> ractInvoker.java:124)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:82)
>
> ... 31 more
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: CXF 2.0.3 Introduces "wrong number of arguments" fault?
Posted by Daniel Kulp <dk...@apache.org>.
Christopher,
I don't think it was "intentional". It's probably a sideaffect of some
of the cleanup we did around getting the out of band headers to actually
work. Looking at the code and stuff, it probably would work if the
header parameter wasn't the last one. When reading the body part in,
the array would be updated with null for the the params before the body
part.
The other workaround would involve writing an itnerceptor to grep the
param list and check the length and stuff. Not exactly fun.
In anycase, I can reproduce it and I'm working on a fix now. However,
I'm on a plane coming back from ApacheCon and I'm heading on vacation
(with very limitted connectivity) tomorrow so I'm not sure when I'll get
it committed. (or even when I'll get this email sent)
Dan
On Thursday 15 November 2007, Christopher Moesel wrote:
> Hello,
>
>
>
> I am using CXF with my JAX-WS WSDL-first web service. My schema
> specifies a mandatory custom credentials element in the SOAP header.
>
>
>
> With CXF 2.0.2, if the client sent a request that was missing that
> custom credentials element in the header, it would come into the
> implementation code as null. This was good, because I could handle it
> as I wanted to from there.
>
>
>
> With CXF 2.0.3, it never even makes it to my implementation code.
> Instead, a soap:server fault is automatically sent back to the client.
> The message of the fault says:
>
>
>
> wrong number of arguments while invoking public
> com.mycompany.MyOperationResponseType
> com.mycompany.MyWebServiceImpl.myOperation(com.mycompany.MyOperationTy
>pe ,com.mycompany.UserCredentialsType) throws com.mycompany.MyFault
> with params [com.mycompany.MyOperationType@e345c2].
>
>
>
> I'd really like to have control over this-I actually prefer not to
> send back a fault, but rather to respond in a different way. In
> addition, if I *did* want to send back a fault, I wouldn't want the
> fault message to contain my class names-and I would probably want to
> return my custom fault type in the fault details as well.
>
>
>
> Is this by design, or is this a regression? Is anyone aware of a
> workaround for this?
>
>
>
> I have also pasted the stacktrace below. Thanks for your help!
>
>
>
> -Chris
>
>
>
> Nov 15, 2007 4:34:58 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
>
> INFO: Interceptor has thrown exception, unwinding now
>
> org.apache.cxf.interceptor.Fault: wrong number of arguments while
> invoking public com
>
> .mycompany.MyOperationResponseType
> com.mycompany.MyWebServiceImpl.myOpe
>
> ration(com.mycompany.MyOperationType,com.mycompany.UserCredentialsType
>) thro
>
> ws com.mycompany.MyFault with params
> [com.mycompany.MyOperationType@e345c2].
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractIn
>
> voker.java:109)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.createFault(JAXWSMethodInvoke
>
> r.java:76)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:101)
>
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.jav
>
> a:100)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:68)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInv
>
> okerInterceptor.java:56)
>
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecu
>
> tor.java:37)
>
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Se
>
> rviceInvokerInterceptor.java:92)
>
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
>
> orChain.java:207)
>
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainIniti
>
> ationObserver.java:73)
>
> at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(Servlet
>
> Destination.java:79)
>
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(
>
> ServletController.java:256)
>
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletCont
>
> roller.java:160)
>
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCX
>
> FServlet.java:170)
>
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCX
>
> FServlet.java:148)
>
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491
>
> )
>
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:3
>
> 67)
>
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.jav
>
> a:185)
>
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:1
>
> 81)
>
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:6
>
> 89)
>
> at
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)
>
>
>
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHand
>
> lerCollection.java:146)
>
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.
>
> java:114)
>
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:1
>
> 39)
>
> at org.mortbay.jetty.Server.handle(Server.java:285)
>
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:45
>
> 7)
>
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnectio
>
> n.java:765)
>
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:628)
>
> at
> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
>
> at
> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)
>
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
>
> va:329)
>
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool
>
> .java:475)
>
> Caused by: java.lang.IllegalArgumentException: wrong number of
> arguments
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
>
> java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>
> sorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Abst
>
> ractInvoker.java:124)
>
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker
>
> .java:82)
>
> ... 31 more
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog