Wow, thanks for that. Should I go ahead and build my own patched Aegis, or should I wait for you to finish your testing to make sure this is all we need? What project owns the Aegis code now?
-----Original Message----- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 11:47 AM To: [email protected] Cc: Clough, Samuel (USPC.PRG.Atlanta) Subject: Re: Wrong number of Arguments Error Samuel, I managed to track this down. It's a bug in the DepthXMLStreamReader that isn't getting the "END_ELEMENT" events lined up correctly in the Aegis binding. Thus, while reading the first object, it's sucking in all the rest of the data so it doesn't deserialize the second parameter. It then tries to invoke your method with only one parameter. I'm testing a fix now. It's a very simple fix. Change the getElementText() method to look like: public String getElementText() throws XMLStreamException { String ret = reader.getElementText(); depth--; return ret; } According to the spec, the getElementText() method consumes the characters and end events and leaves it in the "end" position. This. takes care of keeping the depth correct. In anycase, this probably affects Aegis really badly. Not sure how much of anything in Aegis has worked. Dan On Tuesday 17 July 2007 08:46, Clough, Samuel (USPC.PRG.Atlanta) wrote: > Every time I send this with a code zip attached it is bounced as spam, > so I'll try to send you the code zip offline. > > This is a java first case. What we are doing is hooking up > applications that are completely internal, so the wsdl is not so much > of a concern per se for this application because there are no outside > consumers. We're simply trying to connect a few applications in a > loosely coupled way. > > Any help would be GREATLY appreciated as I was in the middle of the > Xfire learning curve and decided to switch to CXF for the future > growth and I'm a little lost and this error is so vague I can't get > anything on it and google hasn't helped much. We're firing up the > service using these calls: > > AegisDatabinding binding = new AegisDatabinding(); > DefaultTypeMappingRegistry tmr = > (DefaultTypeMappingRegistry) binding.getTypeMappingRegistry(); > Configuration config = tmr.getConfiguration(); > config.setDefaultMinOccurs(1); > config.setDefaultNillable(false); > sf.getServiceFactory().setDataBinding(binding); > sf.setServiceBean(serviceBean); > sf.setServiceClass(serviceClass); > sf.setAddress("http://localhost:8192/omnitranmanager/2007/07/OmniTranS >er vice"); > sf.create(); > > The stack trace: > > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: wrong number of arguments > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker. >ja va:88) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker. >ja va:56) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvo >ke rInterceptor.java:56) > at > org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecut >or .java:37) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Ser >vi ceInvokerInterceptor.java:87) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto >rC hain.java:206) > at > org.apache.cxf.transport.MultipleEndpointObserver.onMessage(MultipleEn >dp ointObserver.java:82) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceReques >t( JettyHTTPDestination.java:253) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jet >ty HTTPDestination.java:213) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPH >an dler.java:54) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:71 >2) at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandl >er Collection.java:211) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:13 >9) at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502 >) at > org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection >.j ava:835) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:641) > at > org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202) > at > org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) > at > org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.jav >a: 368) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool. >ja va:442) > Caused by: java.lang.IllegalArgumentException: wrong number of > arguments at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j >av a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess >or Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker. >ja va:69) > > -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: Monday, July 16, 2007 4:23 PM > To: [email protected] > Subject: Re: Wrong number of Arguments Error > > > Is this a "java first" case or a "wsdl first" case? Are there > headers or soap w/ attachments involved? Also, is it a "wrapped" > doc/lit, "bare" doc/lit, or rpc/lit? > > If it's a java first case with a wrapped doc/lit endpoint, can you try > running java2wsdl with the "-s dir" flags to generate the wrapper > types. > > That SHOULD work better. > > Is there anyway you can send along the wsdl and the service > interface/class? (You can send to me privately if that's preferred) > > If I can get a reproduceable test case, it should be much easier to > debug. > > Dan > > On Monday 16 July 2007 15:56, Clough, Samuel (USPC.PRG.Atlanta) wrote: > > I'm looking for any help I can get on debugging a "wrong number of > > arguments error." I'm getting from a cxf service hosted via the > > embedded Jetty server. We just started a new project and used XFire > > for the web services and then ripped it out and put in CXF and don't > > have much experience with either so I'm definitely on the wrong end > > of the learning curve. Anyway, for one service that takes an simple > > object as a parameter is constantly throwing "wrong number of > > arguments" The stack track points all the way down the Sun > > reflection calls. I've tried stripping out the boolean and Date > > properties until I'm left with just 7 String properties and I'm > > still getting the error every time the service is called. Does > > anyone have any idea how I can debug this further? I just can't > > find what is causing the problem and I've spent about 7 hours on > > this now. Other calls on the same service class work fine and if I > > strip the parameter class down to just one or two string properties > > it works. Any help would be greatly > > appreciated! > > -------------------------------------------------------- -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog -------------------------------------------------------- Princeton Retirement Group, Inc - Important Terms This E-mail is not intended for distribution to, or use by, any person or entity in any location where such distribution or use would be contrary to law or regulation, or which would subject Princeton Retirement Group, Inc. or any affiliate to any registration requirement within such location. This E-mail may contain privileged or confidential information or may otherwise be protected by work product immunity or other legal rules. No confidentiality or privilege is waived or lost by any mistransmission. Access, copying or re-use of information by non-intended or non-authorized recipients is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail. The transmission and content of this E-mail cannot be guaranteed to be secure or error-free. Therefore, we cannot represent that the information in this E-mail is complete, accurate, uncorrupted, timely or free of viruses, and Princeton Retirement Group, Inc. cannot accept any liability for E-mails that have been altered in the course of delivery. Princeton Retirement Group, Inc. reserves the right to monitor, review and retain all electronic communications, including E-mail, traveling through its networks and systems (subject to and in accordance with local laws). If any of your details are incorrect or if you no longer wish to receive mailings such as this by E-mail please contact the sender by reply E-mail. --------------------------------------------------------
