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: [email protected]; [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
> À : [email protected]
> 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
> À : [email protected]
> 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
