XFire

Client generated wrong if header element is not in separate message

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.2.6
  • Fix Version/s: None
  • Component/s: Generator
  • Labels:
    None
  • Number of attachments :
    2

Description

If an object is expected to be passed in the header, and the wsdl defines it as a part in the request message (rather than in its own message), then XFire generates the client incorrectly. For each operation using the header, it will define two parameters for the header object. One will be serialized into the soap header and the other will be serialized into the message body. Xfire works correctly, however, if the header is defined in its own message instead of as a part in the request message.

This causes interoperability problems with CXF 2.0 RC, since CXF currently requires header objects to be defined as a part in the request message. This is apparently the OS-I suggested way of doing things. See https://issues.apache.org/jira/browse/CXF-602 and http://www.mail-archive.com/cxf-user@incubator.apache.org/msg00231.html.

I'll try to get a quick example together to demonstrate this.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Chris Moesel added a comment -

Attached a working example of the bug (or would that be a non working example of the bug?).

Please see the readme.txt at the root of the extracted folder.

Show
Chris Moesel added a comment - Attached a working example of the bug (or would that be a non working example of the bug?). Please see the readme.txt at the root of the extracted folder.
Hide
Permalink
Tomasz Sztelak added a comment -

Maybe do you have any documents which describe mapping wsdl to java for this case ?

Show
Tomasz Sztelak added a comment - Maybe do you have any documents which describe mapping wsdl to java for this case ?
Hide
Permalink
Alexander Bollaert added a comment -

I think the error is somewhere in org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator. When it creates the ParamInfo, it iterates over the messages parts first. Suppose you have defined an input message defined as:

 
	<message name="getSnapshotReportRequest">
		<part name="parameters" element="messages:getSnapshotReport" />
		<part name="header" element="messages:HeaderElement" />
	</message>

It will just generate 2 ParamInfo objects with header set to false.

After that, it iterates over the bindings, and it will encounter this:

			<input>
				<soap:body use="literal" parts="parameters" />
				<soap:header use="literal" part="header"
					message="tns:getSnapshotReportRequest" />
			</input>

Here it should take into account that the header already has a ParamInfo (it knows which message and part it is), and change the header boolean from false to true. Instead it just generates an extra parameter (Header2) with header set to true. I've currently fixed this on the 1.2.6 code because it was too much work to change my interfaces at each generation time. If you want I can attach a patch.

Show
Alexander Bollaert added a comment - I think the error is somewhere in org.codehaus.xfire.gen.jsr181.AbstractServiceGenerator. When it creates the ParamInfo, it iterates over the messages parts first. Suppose you have defined an input message defined as: <message name="getSnapshotReportRequest"> <part name="parameters" element="messages:getSnapshotReport" /> <part name="header" element="messages:HeaderElement" /> </message> It will just generate 2 ParamInfo objects with header set to false. After that, it iterates over the bindings, and it will encounter this: <input> <soap:body use="literal" parts="parameters" /> <soap:header use="literal" part="header" message="tns:getSnapshotReportRequest" /> </input> Here it should take into account that the header already has a ParamInfo (it knows which message and part it is), and change the header boolean from false to true. Instead it just generates an extra parameter (Header2) with header set to true. I've currently fixed this on the 1.2.6 code because it was too much work to change my interfaces at each generation time. If you want I can attach a patch.
Hide
Permalink
Alexander Bollaert added a comment -

This patch fixes the issue for me, but I haven't done much further checking...

Show
Alexander Bollaert added a comment - This patch fixes the issue for me, but I haven't done much further checking...

People

  • Assignee:
    Tomasz Sztelak
    Reporter:
    Chris Moesel
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: