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 [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