Just to come back on the second problem (I've just said it was generated
"more or less" properly)...
The namespace version holder (SPEC_NAMESPACE_SET) isn't generated in the
(concrete) home class.
I tracked it down to be due to "Wsdl2Java.buildServiceProperties" and,
in particular, "isDraft01Specific" and "isDraft05Specific" (nothing
happens it's not specific to either 01 or 05). I guess that this will
teach me once again that I should use the template instead of my own
WSDL, but presumably this issue should be resolved some day when the
project is updated for the latest WSRF specs.
Bruno.
Bruno Harbulot wrote:
Hi,
I've found one of the causes of this problem. I think this is either a
WSDL2Java bug or I'm misinterpreting the WSDL requirements.
It seems that WSDL2Java (as part of Apache-WSRF) doesn't like empty
message types.
The custom messages looked like this:
<message name="markMilestoneRequestMsg">
<part element="types:markMilestoneRequest"
name="markMilestoneRequestSoapMsg" />
</message>
<message name="markMilestoneResponseMsg" />
<message name="startRequestMsg" />
<message name="startResponseMsg" />
<message name="endRequestMsg" />
<message name="endResponseMsg" />
When I use messages that are not empty (for all of them, in particular
all the requests), such as:
<message name="startRequestMsg">
<part element="types:startRequest"
name="startRequestSoapMsg" />
</message>
with corresponding empty elements in the schema for NS "types":
<element name="startRequest" />
all the methods are generated more or less properly.
(There is another problem, but I think it's unrelated).
In effect, from the stub side (as generated by Axis's WSDL2Java and
WSRF's WSDL2Java), if forces to have a parameter to methods that
wouldn't take one otherwise (in my case, "start" and "end", for example:
"start(null)" instead of "start()").
To this extent, I think this is a bug in WSRF's WSDL2Java. I couldn't
find it in the JIRA database, though.
It's definitely a minor bug, but it's annoying for interoperability with
other implementation of the same services. Would it be possible to fix
this?
Cheers,
Bruno.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
