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<Param> 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? 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 >
