cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <>
Subject Implement JSR311 in CXF. WAS: RE: Feedback on RESTful services in CXF
Date Wed, 29 Aug 2007 03:35:03 GMT

> -----Original Message-----
> From: Dan Diephouse []
> Sent: 2007?8?29? 4:34
> To:
> Subject: Re: Feedback on RESTful services in CXF
> Trenaman, Adrian wrote:
> > 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...). 
> >
> >   
> 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. 


> </pontification>
> - Dan
> -- 
> Dan Diephouse
> MuleSource
> |

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

View raw message