That is when the -f:unwrap comes into the picture. It can bring you back
to simple data types. Unfortunately there is not a whole lot of
documentation there to explain how the "unwrap" process works and what
the rules are. This is especially true when I am creating my own wsdl
file.
I also noticed that the -f:wsi appears to be active when I supply my
wsdl file, mostly it seems to do some ws-I compatibility validation of
the wsdl file. Again, I'd like to see far mode documentation of this
option other than stating that this is the ws-I compatibility flag.
John
-----Original Message-----
From: Merten Schumann [mailto:Merten.Schumann_at_asg.com]
Sent: Friday, August 06, 2004 5:45 AM
To: users_at_jax-rpc.dev.java.net
Subject: RE: -f:wsi
> -----Original Message-----
> From: Kevin Jones [mailto:kevinj_at_develop.com]
> Sent: Friday, August 06, 2004 11:11 AM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: -f:wsi
>
> OK,
>
> so the binding is rpc-literal, but I can achieve that with
> -f:rpcliteral
> (BTW, you really should be using doc/literal which you turn
> in with the
> -f:documentliteral feature if you want the best shot at
> interoperability)
on my TODO list I've got "check docliteral encoding with my web service"
but, I found that even for simple parameters/return types, like Strings,
in docliteral mode complex types get generated to the WSDL
in the past I had some bad experiences with complex types when I tried
to use such WSDLs in SOAP client implementations like Mozilla Web
Services Impl or SOAP::Lite ...
Merten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net