Hi, I think a response like
<ns1:getUserByUsernameResponse xmlns:ns1="http://jivesoftware.com/clearspace/webservices";> <return> <email>[email protected]</email> <ID>2001</ID> <name>user1 user1</name> <username>user1</username> </return> </ns1:getUserByUsernameResponse> indicates that a response being formatted/wrapped according to soap rules, so it is unlikely the JAXRS runtime will be capable of formatting the same way. Now, I'm planning to support CXF Data Bindings wrapped as JAXRS message providers but I'm not sure it will help in this case. So with JAX-RS/JAXB you'll have something like <user xmlns="somenamespace"> <email>[email protected]</email> <ID>2001</ID> <name>user1 user1</name> <username>user1</username> </user> I don't see what can be done at the JAXRS level to ensure that the HTTP-Binding like response is returned. You may want just to move to JAX-RS right now rather than postponing it and register an XMLStreamWriter from a JAXRS ResponseHandler filter which upon encountering a root element would replace it with a boilerplate xml like <ns1:getUserByUsernameResponse xmlns:ns1="http://jivesoftware.com/clearspace/webservices";> <return> and then after letting the document out finish it with </return> </ns1:getUserByUsernameResponse> I'm presuming the name of the operation is "getUserByUsername", you can get it from an input message which you can pass into your custom stax writer upon creating it in the filter. If your legacy clients were distinguishable somehow from the newer ones (say they have some unique header, etc) then you can do it for old clients only. It is just difficult for us to continue working with the HTTP Binding given that JAX-RS is a much richer spec. I'd vote for dropping it completely for 2.3 given that various new contributions are expected though still maintaining it in 2.2 fixes. Now about the list response : <ns1:getUsersResponse xmlns:ns1="http://jivesoftware.com/clearspace/webservices";> <return> <email>[email protected]</email> <ID>2003</ID> <name>User Test One</name> <username>userTest1</username> </return> <return> <email>[email protected]</email> <ID>2002</ID> <name>user2 user2</name> <username>user2</username> </return> </ns1:getUsersResponse> May be we should do in JAX-RS something like <users xmlns="namespace used by user or package name derived"> <user> <email>[email protected]</email> <ID>2003</ID> <name>User Test One</name> <username>userTest1</username> </user> <user> <email>[email protected]</email> <ID>2002</ID> <name>user2 user2</name> <username>user2</username> </user> </users> And also introduce some annotations which will give a hint to the runtime on how to customize the wrapping of the list Cheers, Sergey -----Original Message----- From: Gabriel Guardincerri [mailto:[email protected]] Sent: 16 June 2009 19:37 To: [email protected] Subject: Re: How to migrate REST HTTP-binding to JAX-RS and keep the xml messages format? Hi Sergey, > > So what difference in formats is there when you try to switch to JAX-RS (with > JAXB 2.1 being the default provider) ? When you switch, do you issues with > all the XML samples you posted or is it with PUT only ? When I switch to JAX-RS with it's default provider I have problems with all the methods that are in the XML samples. But for PUT or POST I'm getting a java error, so it may be the qualified namespace that Daniel mention, I trying to fix and test it again. On the other side there are differences with GET requests. For the service "Get User", I get: Request: GET http://localhost:8080/rpc/rest/userService/users/user1 Responses: With HTTP-binding in 2.0.x: <ns1:getUserByUsernameResponse xmlns:ns1="http://jivesoftware.com/clearspace/webservices";> <return> <email>[email protected]</email> <ID>2001</ID> <name>user1 user1</name> <username>user1</username> </return> </ns1:getUserByUsernameResponse> With JAX-RS with its default provider in 2.2.2: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <User> <email>[email protected]</email> <ID>2001</ID> <name>user1 user1</name> <username>user1</username> </User> And for service "Get Users" Request GET http://localhost:8080/rpc/rest/userService/users Responses: With HTTP-binding in 2.0.x: <ns1:getUsersResponse xmlns:ns1="http://jivesoftware.com/clearspace/webservices";> <return> <email>[email protected]</email> <ID>2003</ID> <name>User Test One</name> <username>userTest1</username> </return> <return> <email>[email protected]</email> <ID>2002</ID> <name>user2 user2</name> <username>user2</username> </return> </ns1:getUsersResponse> With JAX-RS with its default provider in 2.2.2: ".No message body writer found for response class : ArrayList." > As Dan said, you can register a Stax XmlStreamReader or Writer (in CXF > interceptors or JAX-RS filters). For ex, you can check if it's PUT and no > namespace is there and adapt as needed - let us know please if/when you > decide to go this route to make a smoother migration, we can provide some > code samples... Well, PUT services aren't working right now with JAX-RS in 2.2.2, but they work with HTTP-binding in that version. If we couldn't find a solution for GET with HTTP-binding in 2.2.2 then yes, I'll need to go this route and I'll appreciate code samples :). But for now I just prefer to see how HTTP-binding fix goes before going this way that will imply code migration and a fix to the xml messages format issue. Thank you, Gabriel > > > > > -----Original Message----- > From: Gabriel Guardincerri [mailto:[email protected]] > Sent: 15 June 2009 20:16 > To: [email protected] > Subject: Re: How to migrate REST HTTP-binding to JAX-RS and keep the xml > messages format? > > Hi Dan and Sergey, > >>> The main change between them that MAY affect the XML binding is going from >>> JAXB 2.0.x to JAXB 2.1.x. The generated code from xjc can be quite >>> different and could potentially change things. > > Dan, it may be that change. Our code works on 2.0.7, but it doesn't > work on 2.1.5 nor 2.2.2. If there is a way to fix that I'll really > appreciate it. We want to use the latest version 2.2.2 and JAX-RS for > some new web services that we need to build. But we need to keep > backward compatibility with the old web services that we have. So the > best, meaning less effort, option is to have a fix for HTTP-binding in > version 2.2.2. We are planning to migrate this old services, but not > now. > > The problem is only with URL params. All our GET and DELETE services > that use some URL param don't work, they always get null values. > > For example > > For this service > > @WebMethod > @Get > @HttpResource(location = "/users/{username}") > WSUser getUserByUsername(@WebParam(name = "username")String username) > throws UserNotFoundException; > > Using this request > > GET http://localhost:8080/rpc/rest/userService/users/user1 > > It doesn't work. The username param has a null value. Is there a way > to get a patch for that? > >> It is interesting. It would be helpful if Gabriel could post two sample XML >> instances, one showing what the clients are currently getting and what they >> would get if CXF 2.2.2 were used, we can proceed from there... > > Sergey, actually when using HTTP-binding with CXF 2.2.2 we get the > same XML, the problem is what I mention above, that some methods don't > get params. So we were thinking on migrating them to JAX-RS to make it > work, but we need to configure it to use the same XML messages format > that we have for HTTP-binding. I'm attaching some xml samples > request/response and the interface with the annotations. Sorry that my > first post wasn't a clear. > > Anyway, we prefer to just apply a patch to CXF 2.2.2 to make it work, > instead of migrating our old stuff. We are planning to migrate them > since it was deprecated, but if possible not for our next version, we > are short of time for this release and this problem was unexpected. > > Thanks in advance, > > Gabriel > > On Mon, Jun 15, 2009 at 1:12 PM, Sergey Beryozkin<[email protected]> > wrote: >> Hi Dan, >> >> >> >>> >>> Sergey, >>> >> >> >>> >>> I know a bug was fixed in the HTTP binding for 2.2.2 in regards to the >>> root element things. I'm wondering if that may have affected this or not. >>> >> >> possibly... >> >> thanks, Sergey >> >>> >>> Dan >>> >>> >>> >>> On Sun June 14 2009 3:47:26 pm Sergey Beryozkin wrote: >>>> >>>> Hi, >>>> >>>> As far as I'm aware no significant changes have been made to the HTTP >>>> binding recently, I haven't done any work with it for sure. Perhaps >>>> there've been some cosmetic changes but I'm not aware of them. >>>> >>>> We've agreed to deprecate the HTTP binding as all the focus now is on >>>> enhancing the JAX-RS runtime. >>>> >>>> > The problem is that we need to keep the same XML messages format for >>>> >>>> backward compatibility. >>>> >>>> Can you please post a sample class annotated with HTTPBinding >>>> annotations and XML message which is expected by current clients ? >>>> >>>> Thanks, Sergey >>>> >>>> >>>> -----Original Message----- >>>> From: Gabriel Guardincerri [mailto:[email protected]] >>>> Sent: 12 June 2009 20:08 >>>> To: [email protected] >>>> Subject: How to migrate REST HTTP-binding to JAX-RS and keep the xml >>>> messages format? >>>> >>>> >>>> Hi, >>>> >>>> We have a lot of WS that were implemented using HTTP-binding of CXF >>>> 2.0.11, >>>> but when we tried to migrate CXF to 2.2.2 we found out that HTTP-binding >>>> do >>>> not pass params correctly. So we were trying to migrate those services >>>> to >>>> JAX-RS. The problem is that we need to keep the same XML messages format >>>> for >>>> backward compatibility. We tried with the three data binding providers >>>> that >>>> are in the jaxrs package XMLBeansElementProvider, JAXBElementProvider >>>> and >>>> AegisElementProvider, but none of them have the same XML format for >>>> messages >>>> that HTTP-binding has. >>>> >>>> Is there a way to do so? I mean, to implement services with JAX-RS and >>>> use >>>> the same XML data binding that has HTTP-binding? Or a way to build the >>>> same >>>> XML messages? >>>> >>>> Of course, if there is a way to make HTTP-binding work in version 2.2.2 >>>> or >>>> 2.1.5, it will be the best solution. >>>> >>>> Thanks, >>>> >>>> Gabriel >>> >>> -- >>> Daniel Kulp >>> [email protected] >>> http://www.dankulp.com/blog >> >
