It would definitely require a "little" work to get the JAX-RS stuff to match
the same XML.
Basically, you would need to create a new JAXB bean:
@XmlRootElement(name = "getUserByUsernameResponse")
public class GetUserByNameResponse {
@XmlElement(name = "return")
User user;
....
}
and change your return type in your method to that. GetUsers would be the
same:
@XmlRootElement(name = "getUsersResponse")
public class GetUserResponse {
@XmlElement(name = "return")
List<User> user = new ArrayList<User>();
....
}
I THINK that would work.
Dan
On Wed June 17 2009 10:59:53 am Gabriel Guardincerri wrote:
> Hi Sergey,
>
> Thank you for your detailed post. It seems to be really hard to have the
> same XML format. For now, I'll wait for a patch to HTTP-binging, I'm also
> debuging it myself trying to see if I find the problem. But we will
> probably need to think on the alternative of breaking backward
> compatibility and to migrate all to standard JAXRS for future releases.
>
> Thank you,
>
> Gabriel
>
> Sergey Beryozkin-2 wrote:
> > Hi,
> >
> > I think a response like
> >
> > <ns1:getUserByUsernameResponse
> > xmlns:ns1="http://jivesoftware.com/clearspace/webservices";>
> > <return>
> > [email protected]
> > <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 protected]
> > <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 protected]
> > <ID>2003</ID>
> > <name>User Test One</name>
> > <username>userTest1</username>
> > </return>
> > <return>
> > [email protected]
> > <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 protected]
> > <ID>2003</ID>
> > <name>User Test One</name>
> > <username>userTest1</username>
> > </user>
> > <user>
> > [email protected]
> > <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 protected]
> > <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 protected]
> > <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 protected]
> > <ID>2003</ID>
> > <name>User Test One</name>
> > <username>userTest1</username>
> > </return>
> > <return>
> > [email protected]
> > <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
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
