Daniel, Oh intresting, actually only "GET" and "DELETE" that have params in the URL have problems. All PUTs and POSTs (or GET/DELETE without params) work. Anyway those incoming messages are just for testing proposes, so we can changed them to be namespace qualified. Thanks for the finding.
Gabriel On Mon, Jun 15, 2009 at 4:45 PM, Daniel Kulp<[email protected]> wrote: > > Gabriel, > > Is it just the createUserWithUser message (and the PUT version) that is having > the problem or are all the "Gets" also problematic? > > That incoming message really looks suspect. The createUserWithUser message > isn't namespace qualified at all which would be invalid per any of the schema. > Thus, I'm surprised that even worked with 2.0.x. Is there any way you > could try a POST (with wget or something) of the message, but namespace > qualify it? I'm curious if that would work. Most likely, if you are > going to want the message accepted, you'll need to write an interceptor that > would "fake" a namespace on that element. Basically, wrapper the > XMLStreamReader with a new one that would map that element name into a > qualified version of it. > > Dan > > > > On Mon June 15 2009 3:16:03 pm Gabriel Guardincerri wrote: >> 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 >
