This is the message that is causing the problems.
There may be a bug somewhere that caused this to "leak through" because this is the only message the breaks the interoperability protocol. So the originators of the WSDL may need to be notified about this problem - and maybe they will take action to fix it.
In the meantime - I'm not sure how critical the Retrieve operation is to what you are trying to do (the name doesn't bode well - however maybe you'll be able to use the "RetrieveMultiple" method instead to retrieve a single instance in a collection) - you should be able to make some modifications to a copy of the WSDL to see if you can get the rest to work under Axis2/JAX-WS (Axis 1.x is a lost cause I'm afraid).
delete the RetrieveSoapIn and RetrieveSoapOut message in the portType section delete the Retrieve operation in the binding section delete the Retrieve Operation Now try to generate a stub from modified WSDL.
If you need access of the Retrieve method and a fix to the method isn't forth coming (fast enough) then you'll need to
hand code the generation of the SOAP RetrieveSoapIn requests and the parsing of the RetrieveSoapOut responses on a
separate client stub. In Axis2 this amounts to using
org.apache.axis2.client.Call and building requests /parsing responses with
org.apache.axis2.soap.SOAPEnvelope. Web services are supposed to have a stateless design - if yours does not then you will also need to code the SOAP interaction of the methods that are required to "build the state" required before you can call the Retrieve method. So basically
You have to identify the "Retrieve" interactions necessary for your client. You need to be specific enough so that you can code up representative scenarios in a tracer bullet/spike/vertical slice. Use .NETs WSDL.exe to create a stub and code a minimal console app (in C# (or J#)) to exercise the representative scenarios. Capture the SOAP request/response pairs with tcpmon as your baseline input/output requirements for your Java based stub. Now code up the scenarios one by one with your chosen Java API. As you go, refactor the interactions to a more generalized stub to be used by your client application.