Trenaman, Adrian wrote:
First problem: I didn't realise that I needed to have a
package-info.java 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 package-info.java file in the Java package (it's still not
clear to me why I should need it...).
I hate how JAXB defaults to UNQUALIFIED, its rather silly.
Did you file a JIRA for this? Sounds like a bug in the schema parsing code.
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.
Did you file a JIRA for this? Sounds like a bug in an interceptor. I
would like to see the stack trace and see if we can get this fixed for
2.0.2.
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?
This is part of the problem of trying to fulfill the WSDL2 HTTP Binding.
I should probably look up the details of whats required here.
<pontification>
My original intention was to support the WSDL2 HTTP binding, but its
ended up in soooo many confusing things that I'm beginning to think the
whole HTTP binding as it currently stands is a mistake.
After playing with Jersey (the Sun JSR 311 impl) for a bit, I'm much
more inclined to go down that route. The WSDL model just doesn't work
with REST at all. Right now we have all sorts of weirdness -
wrapped/unwrapped mode being the biggest one. Its a source of
never-ending confusion to users.
Which brings us to the question - how do you properly integrate RESTful
support into a web service framework which operates on a WSDL model :-)
Regarding the future of our REST support, I suppose we have two roads to
go down:
1. Build our own JSR 311 impl. Cons: mapping the internal WSDL like
model to a RESTful one
2. Create bridges to something like Jersey. i.e. we would just proxy the
request. Although at this point, I'm a bit confused as to what value
we're really providing.
Thoughts?
</pontification>
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
