Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of adrian.trenaman@iona.com
 designates 62.221.12.55 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Feedback on RESTful services in CXF
Date: Wed, 29 Aug 2007 10:08:08 +0100
Message-ID: <1D195F515BDFE04EA40FA8D046308D6AE4D0DC@emea-ems1.IONAGLOBAL.COM>
In-Reply-To: <46D486A2.3040508@mulesource.com>
Thread-Topic: Feedback on RESTful services in CXF
Thread-Index: AcfpwHCnhRpq2G+nRxG13iaRWORYbAAWlYKQ
From: "Trenaman, Adrian" <Adrian.Trenaman@iona.com>
To: <cxf-dev@incubator.apache.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dan,=20

Thanks for this - have raised CXF-952 and CXF-954 for issues one and two
respectively.=20

<pontificationResponse> <!-- Ha ha: Hurray for Wrapped Doc Literal-->
I hadn't realised that we were using a WDSL model under the covers for
our RESTful services; sounds to me like we're pushing a big stone up a
big hill with this approach (as per Jervis's email). There is something
very cool about having a the restful_http_binding demo that lets the
same service be exposed as a web service, XML RESTful service, and JSON
RESTful service, but then, I don't know of anyone who really requires
that kind of flexibility in a production system: designers will have
decided to go one way or the other (WSDL service or REST service). Given
that trying to do both with the same core is causing us grief, I think
it makes sense to separate them out at this point.=20

Having our own support for JAX-RS sounds much more attractive: if we
need to implement it ourselves on Apache for licensing reasons then
let's fire ahead. If we can piggyback on Jersey then I'm happy with that
too. If the former, should we spin off a separate Apache project?=20
</pontificationResponse>

Cheers,
Ade.=20

-----Original Message-----
From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]=20
Sent: 28 August 2007 21:34
To: cxf-dev@incubator.apache.org
Subject: Re: Feedback on RESTful services in CXF

Trenaman, Adrian wrote:
> First problem: I didn't realise that I needed to have a=20
> package-info.java in the package. Without this, my Person object=20
> (which represents the payload of the PUT) has null contents in the=20
> serverside code. Through a lot of trial and error I discovered that I=20
> hadn't included package-info.java file in the Java package (it's still

> not clear to me why I should need it...).
>
>  =20
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=20
> document's root element is not prefixed with an XML namespace prefix.=20
> For example; the following valid XML results in a server-side
NullPointerException.
> =20
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=2E0.2.
> =20
> Third problem: in the update scenario, if I send the XML to=20
> /people/123 then the ID (123) gets injected into the payload over the=20
> existing id (42). I think this behaviour, where we override the data=20
> in the payload, may lead to a lot of confusion: what if someone wants=20
> 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=20
> reject the call if the "injecting" parameters don't match the payload?
>  =20
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=2E 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

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