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 [EMAIL PROTECTED]
>
>
>
> 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
> [EMAIL PROTECTED]
>
>         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
[EMAIL PROTECTED]
http://www.dankulp.com/blog

Reply via email to