> -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 2007?8?29? 4:34 > To: [email protected] > Subject: Re: Feedback on RESTful services in CXF > > > 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?
I should have mentioned in the dev list that I just started looking into implementing JSR311 in CXF. I have tried both, i.e.: 1. Building JSR311 impl based on CXF specific APIs and concepts, such as service model, frontend, bindings, serviceFactoryBean/serverFactoryBean etc. The biggest problem I ran into is that currently CXF core is very much WSDL-centric. I did some hacks to make the core APIs are not bonded to WSDL directly, for example, the Endpoint, EndpointInfo, AbstractServiceFactoryBean, AbstractEndpointFactory, Binding etc, the intension is that they just represent a generic service so that I can extend them with a non-WSDL based programming model. But I am not very happy with what I've got so far. IMO, I don't think we should map JSR311 model (a REST model or a resource-oriented model) to an internal WSDL model, actually it is impossible to do so I believe. 2. Jersey's approach: Well, one benefit of doing this in CXF is that you will have an Apache licensed JSR311 implementation. Currently I am working on a prototype for approach one mentioned above. I hope I can send out some concrete codes and documents to the dev list for review and detailed discussions by early next week. Jervis > </pontification> > > - Dan > > -- > Dan Diephouse > MuleSource > http://mulesource.com | http://netzooid.com/blog > > ---------------------------- IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
