Bugzilla – Full Text Bug Listing
|Summary:||Faults returned to C client|
|Product:||C WS Core||Reporter:||Sam Lang <email@example.com>|
|Component:||C WSRF core||Assignee:||Joe Bester <firstname.lastname@example.org>|
In some cases (when an error occurs in the container instead of the service) don't have valid WS-Addressing header elements, so the client fails with an error about missing WS-Addressing stuff instead of displaying the real fault error.
This should be fixed but needs to be tested.
Taking ownership of all of slang's WSC bugs.
There seem to be at least two different problems handling these sorts of messages. For example, when talking to a java service container and providing an invalid service path, the container response with a soap message containing no headers at all, just a fault in the body. Checking the spec, it looks like the header block is optional, so the client bindings code should probably be a bit more careful. It's probably worthwhile to invok the response trigger if there's no header, but if it fails (missing addressing headers or whatever) ignore that unless the body doesn't contain a fault. When doing the same thing to the c container, the response is constructed with some of the ws addressing headers, but the wsa:RelatesTo header contains no content. This confuses the ws-addressing handler.
I committed some fixes to the service side in the c code. The check for message id in the response handler was checking the wrong value for nullness, and thus not generating an error. Fixing that triggered a recursive fault generation problem in the messaging API which is also fixed, so clients talking to the services can figure out the proper error now. The java behavior of omitting the soap:header element will require more changes to the bindings generator to get things handled more nicely.
Committed a fix to the java case (fault without any headers) this in the trunk. The java code reported doesn't actually generate this type of error any more in the gt4.0 branch. While fixing this bug, I restructured the client stubs a bit in the trunk so that the client state machine is now in the soap messaging library instead of in the bindings implementation of each operation. This change will make fixing state machine bugs much simpler (direct code to change, one package to update), and will also make features like intra-container invocation of services much easier to implement. joe