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

Reply via email to