Sorry, it is my bad. What I really meant to say is: You have to set your REST service to WRAPPED mode if you want URL template /employees/{id} maps to a simple type "long id". In the UNWRAPPED mode CXF HTTP binding marshals the request (the URL in the case of HTTP GET) into a wrapper class, i.e., GetEmployee. If you have access to svn, a system test located under \trunk\systests\src\test\java\org\apache\cxf\systest\rest\BookServer.java tells everything.
BTW, in the wrapped mode, argument type long instead of Long (Employee getEmployee(@WebParam(name="id") long id) should also work. What happens is in the interceptor chain, wrapper element is getting striped off, i.e., <GetEmployee><id>somevalue</id></GetEmployee> turns into <id>somevalue</id>, then <id>somevalue</id> is being feed into JAXB, both long or Long are valid output from JAXB. Cheers, Jervis > -----Original Message----- > From: Jean-Sebastien Bournival > [mailto:[EMAIL PROTECTED] > Sent: 2007?8?17? 21:07 > To: cxf-user@incubator.apache.org; [EMAIL PROTECTED] > Subject: RE: AJAX -> [JSON] -> REST service > > > Ok now it works, but here's the thing: > > I switched to unwrapped mode. This time it's throwing me this: > > INFO: URIParameterInterceptor handle message on path > [/employees/33] with content-type [null] > 2007-08-17 08:46:25 > org.apache.cxf.phase.PhaseInterceptorChain doIntercept > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: You can not map a URI > parameter to a simple type when in unwrapped mode! > at > org.apache.cxf.binding.http.IriDecoderHelper.buildDocument(Iri DecoderHelper.java:216) > at > org.apache.cxf.binding.http.interceptor.URIParameterInIntercep > tor.mergeParams(URIParameterInInterceptor.java:129) > at > org.apache.cxf.binding.http.interceptor.URIParameterInIntercep > tor.handleMessage(URIParameterInInterceptor.java:105) > ... (more) > > > I changed back my service to wrapped mode (just doing what > the stack trace told me!). And then I had the idea to change > my method argument to Long (the wrapper type). It works ... > > What is it with primitive types? Is there a problem using > them against a REST service? > > Thanx a lot guys! > > JS. > > > > > > ________________________________ > > De : Dale Peakall [mailto:[EMAIL PROTECTED] > Envoyé : 17 août 2007 02:44 > À : cxf-user@incubator.apache.org > Objet : Re: AJAX -> [JSON] -> REST service > > > I think you also need to associate some meta-data with the id > parameter in your method signature since Java doesn't > maintain any information about parameter names. You can do > this with the @WebParam annotation, e.g. > > @Get > @HttpResource(location="/employees/{id}") > Employee getEmployee(@WebParam(name="id") long id); > > I think you also need to annotate your implementation class, > not just the interface. > > Jean-Sebastien Bournival wrote: > > Thanx for your answer Glen. > > I tried to develop, based on one of the samples, a > small REST web service. It works. But there is a small > thing I can't understand: It's the parameter mapping in the REST uri. > > I have a method in my service interface declared in a > way that it expects an employee id: > > @Get > @HttpResource(location="/employees/{id}") > Employee getEmployee(long id); > > BTW, this doesn't work. I can't understand why. Maybe > I don't get what CXF is doing with the ID in the uri. It's > throwing me this exception when I try to access the URL: > > > http://localhost:8080/cfx-web/services/employeeService/employees/33 > > Thanx for your time. > > JS. > > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract Invoker.java:92) > at > org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvo > ker.java:82) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract Invoker.java:62) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(Ser viceInvokerInterceptor.java:56) > at > org.apache.cxf.workqueue.SynchronousExecutor.execute(Synchrono usExecutor.java:37) > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMes > sage(ServiceInvokerInterceptor.java:92) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn terceptorChain.java:207) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha inInitiationObserver.java:73) > at > org.apache.cxf.transport.servlet.ServletDestination.doMessage( ServletDestination.java:78) > at > org.apache.cxf.transport.servlet.ServletController.invokeDesti > nation(ServletController.java:231) > at > org.apache.cxf.transport.servlet.ServletController.invoke(Serv letController.java:105) > at > org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet. java:271) > at > org.apache.cxf.transport.servlet.CXFServlet.doGet(CXFServlet.java:253) > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt > er(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli cationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardW rapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardC ontextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHost Valve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport Valve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEn gineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap ter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Process or.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHa ndler.processConnection(Http11BaseProtocol.java:664) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolT cpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(Le aderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:684) > at java.lang.Thread.run(Thread.java:595) > Caused by: java.lang.IllegalArgumentException > at > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.cxf.service.invoker.AbstractInvoker.performInvocati > on(AbstractInvoker.java:99) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract Invoker.java:73) > ... 28 more > > > > > > -----Message d'origine----- > De : Glen Mazza [mailto:[EMAIL PROTECTED] > Envoyé : 15 août 2007 16:54 > À : cxf-user@incubator.apache.org > Objet : Re: AJAX -> [JSON] -> REST service > > Am Mittwoch, den 15.08.2007, 13:48 -0400 schrieb Jean-Sebastien > Bournival: > > > Hi guys, > > I am in the process of validating using web > services in conjonction with an AJAX layer on the front-side. > The architecture of this might look like: > > - using CXF to expose REST services > - these services will throw out some JSON (via Jettison) > - the client side will use YUI to access the > service layer > > I have 2 questions for you all: > > 1) Has anyone ever tried that (AJAX -> WS) ? I > thought it might decouples a little more the GUI from the back-end. > > > > > Chapter 10 in Mark Hansen's SOA book covers AJAX -> WS > in general (if not precisely the way you wish to do this). > That sample chapter is available as a free download here: > > http://www.theserverside.com/tt/articles/article.tss?l=AjaxJav aWebServices_Chapter You may need some of the Chapter 9 code to understand Chapter 10--all source code is available at http://soabook.com 2) Are the annotations used in CXF to build a RESTful WS, in sync with what is going on in the JCP regarding JAX-RS (JSR 311 I think) ? AFAIK JSR 311 will be implemented in CXF, and it is a relatively high priority, but it is not there yet. HTH, Glen ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland