cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trenaman, Adrian" <>
Subject Feedback on RESTful services in CXF
Date Tue, 28 Aug 2007 15:31:56 GMT
Hi all,
I've been playing with the RESTful service support and I've come across
some issues that really slowed me down :( I'm describing them here (and
their workarounds) in case any users find it useful. I'm also wondering
if some of these might be classified as bugs - please advise!
Here's what happened: based on the docu in the CXF wiki User Guide [1],
I developed a RESTful service: everything was going fine until I
implemented a PUT method for an update. 
--- in play/ ---
 void updatePerson(Person person);
First problem: I didn't realise that I needed to have a in the package. Without this, my Person object (which
represents the payload of the PUT) has null contents in the serverside
code. Through a lot of trial and error I discovered that I hadn't
included file in the Java package (it's still not
clear to me why I should need it...). 
Also, I've found that elementFormDefault must be QUALIFIED - making this
UNQUALIFIED doesn't work (see below)
--- ---
  namespace = "http://play/", 
        elementFormDefault =
package play;
Second problem: for some reason CXF insists that the payload document's
root element is not prefixed with an XML namespace prefix. For example;
the following valid XML results in a server-side NullPointerException.
 <ns2:Person xmlns:ns2="http://play/">
To get it to work, I had to re-jig the XML so that Person is not
prefixed (see below). I have a feeling that this problem is related to
how we inject the id parameter into the Person XML, perhaps using an
unqualified X-Path like "Person/id", but am not 100% sure. 
 <Person xmlns="http://play/">
The fact that the XML is in unqualified form, while the declaration is in qualified form, is very confusing.
Or am I missing something?  
Third problem: in the update scenario, if I send the XML to /people/123
then the ID (123) gets injected into the payload over the existing id
(42). I think this behaviour, where we override the data in the payload,
may lead to a lot of confusion: what if someone wants to update the id
(or is that RESTful heresy)? what if someone has sent the payload to the
wrong HTTP URL? Would it be better if we simply reject the call if the
"injecting" parameters don't match the payload?



IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message