On Wed June 17 2009 12:02:15 pm Gabriel Guardincerri wrote: > Thank you again for the fast fix! > > Do you know when the next release with the fix is going to be available?
Probably the week of July 20th. Colm is planning on doing a WSS4J release the week of the 13th and we need to get that for some other fixes that are needed. Dan > > dkulp wrote: > > On Wed June 17 2009 11:12:29 am Gabriel Guardincerri wrote: > >> 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. > > > > It's fixed on trunk. Just merged it to 2.2.x. > > > > Workaround provided on the JIRA. > > > > Dan > > > >> 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 > > > > -- > > Daniel Kulp > > [email protected] > > http://www.dankulp.com/blog -- Daniel Kulp [email protected] http://www.dankulp.com/blog
