Originally posted by Brett Daburn:
but my 'operation method' to return the result object is asking for a SOAPElement object as the parameter. That is what I am not following.
My guess is that the WebLogic clientgen tool did the best it could given that {http://services.printable.com/1.0/sso}Authenticate references {http://www.printable.com/pti}PartnerCredentialsType and other elements in the "http://www.printable.com/pti" namespace
The WSDL doesn't even declare namespace prefixes - I had to guess at
xmlns:tns="http://services.printable.com/1.0/sso"
xmlns:s1="http://www.printable.com/sso"
xmlns:s2="http://www.printable.com/pti"
The WSDL (XML schema) imports "http://www.printable.com/sso" and "http://www.printable.com/pti" - but it doesn't provide a schemaLocation! So clientgen wouldn't know what any of the XML types in the "http://www.printable.com/pti" namespace would look like. So it defaulted to assuming that {http://services.printable.com/1.0/sso}Authenticate is some kind of XML document. JAX-RPC uses javax.xml.soap.SOAPElement for generic XML document parameters.
So you can build the "Authenticate" XML parameter as a javax.xml.soap.SOAPElement. However if you are doing that already then using plain old
SAAJ (weblogic 8.1 includes SAAJ 1.1) can become a serious consideration as you are barred from using a more modern web service stack. (
SAAJ client "Java Web Services in a Nutshell" Sample: Chapter 3 SAAJ (PDF))
You shouldn't expect too much from WebLogic 8.1 - it is an
J2EE 1.3 compliant application server. Web services didn't become part of the
Java Enterprise standard until J2EE 1.4. So any web service support in WebLogic 8.1 is vendor specific, non-standard and minimal (i.e. Axis 1.x is even more "standard"). Ultimately that is going to limit to what extent you can coerce clientgen to generate the type of code that you are looking for. clientgen was mainly intended to generate clients for the type of SOAP web services that can be published by a WebLogic 8.1 application server.