I created the jira issue and attached java code to reproduce the problem. Jira issue is CXF-2294. Do you know when you are going to be able to work on it? We need to decide what to do, and a fix for this makes a big difference.
BTW, I'm also trying to debug it to see if I find the problem. Thank you, Gabriel dkulp wrote: > > On Tue June 16 2009 1:35:43 pm Gabriel Guardincerri wrote: >> Hi Daniel, >> >> I tried that patch, but I'm still getting the same error. I also >> debugged it a little bit and notice that that method is invoked only >> for PUT or POST request. But those type of requests are actually >> working for us with the new version of CXF, we don't have problems >> there. Our problem is with GET or DELETE services that have some >> parameter in the URL, like the "getUserByUsername(String username)" >> example in the files that I sent you. >> >> While debugging I also found that the method >> "IriDecoderHelper.buildDocument((XmlSchemaAnnotated schemaAnnotation, >> Collection<SchemaInfo> schemas, List params)" is the one that >> is called for a GET request. And the good news is that when it is >> called it has the parameters that were in the URL and its value. I >> mean, the list "params" has for example one "Param" that is the >> username and its value when I call getUserByUsername service. So it >> seems that at that point everything is OK, and that we lose it after >> that. I was wondering if the problem is when building that document. >> Did that changed? or do you have any other ideas of where the problem >> could be? > > Nope. Nothing on that code path seems to have changed in the http > binding. > Possibly something in the super classes someplace or the model setup or > similar. Don't really know. Any chance you can take your interface (at > least the affected methods) and setup a small test project that shows the > issue and attach to a JIRA? > > Dan > > > >> Thank you, >> >> Gabriel >> >> On Mon, Jun 15, 2009 at 5:00 PM, Daniel Kulp<[email protected]> wrote: >> > Gabriel, >> > >> > Just did a diff of the http binding between 2.1.x branch and the 2.0.7 >> > tag and didn't see anything obvious. There really were not many >> changes >> > to the http binding. >> > >> > HOWEVER, I did see one suspect change. Are you in a position to be >> able >> > to patch and test? Basically, in IriDecoderHelper.java, around line >> > 334, you should see something that looks like: >> > >> > Node node = ec.getFirstChild(); >> > while (node != null) { >> > ec.removeChild(node); >> > node = node.getNextSibling(); >> > } >> > >> > I THINK that may be the cause of the problem. Once the node is >> removed, >> > I'm willing to bet the node.getNextSibling() call returns null. Can >> you >> > try changing the code to: >> > >> > Node node = ec.getFirstChild(); >> > while (node != null) { >> > Node next = node.getNextSibling(); >> > ec.removeChild(node); >> > node = next; >> > } >> > >> > and seeing if that fixes it? >> > >> > Dan >> > >> > On Mon June 15 2009 3:45:50 pm Daniel Kulp 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 > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > > -- View this message in context: http://www.nabble.com/How-to-migrate-REST-HTTP-binding-to-JAX-RS-and-keep-the-xml-messages-format--tp24004576p24075836.html Sent from the cxf-user mailing list archive at Nabble.com.
