Ryan,
The -f:documentliteral options has no effect when starting from a WSDL.
The -f:wsi option verifies that the WSDL is ws-i compliant
and also does not uwrap wrapper cases. You can use the -f:wsi flag with
the -f:unwrap option to unwrap the wrapper cases though.
Give that a try and see if it works for you.
Ryan LeCompte wrote:
>Doug,
>
>I also notice that the generated Java classes are a bit different when going
>from a WSDL file to the Java interfaces with specifying the -f:wsi option in
>addition to -f:documentliteral. If you specify the -f:wsi option with the
>-f:documentliteral option, then the main Java endpoint interface uses
>"wrapper" classes as the arguments to methods corresponding to operations in
>the WSDL file. If you only specify the -f:documentliteral option without the
>-f:wsi option, then the generated Java endpoint interface doesn't specify
>the wrapper classes as the method arguments but rather the regular Java
>class as the argument, such as MyObject ( as oppposed to the generated
>wrapper). However, when using DII you still need to wrap MyObject with the
>generated wrapper/holder class. Should I be okay with just specifying the
>-f:documentliteral and not the -f:wsi when starting with the Java endpoint
>interface as well as when I'm starting with a WSDL file that was previously
>generated with just the -f:documentliteral option?
>
>Thanks!
>
>-- Ryan
>
>-----Original Message-----
>From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com]
>Sent: Friday, October 29, 2004 1:25 PM
>To: users_at_jax-rpc.dev.java.net
>Subject: RE: DII client accessing .NET web service
>
>Doug,
>
>Thanks for responding. So this means that I can just use -f:documentliteral
>and not specify the -f:wsi option and my generated WSDL/classes will be WSI
>1.0 compliant, correct?
>
>Thanks,
>
>-- Ryan
>
>-----Original Message-----
>From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
>Sent: Friday, October 29, 2004 12:56 PM
>To: users_at_jax-rpc.dev.java.net
>Subject: Re: DII client accessing .NET web service
>
>Ryan,
>The -f:wsi switch really does not do anything when starting from Java except
>that it changes the default from rpc/encoded to rpc/lit. To get doc/lit you
>must specify the -f:documentliteral option.
>
>Ryan LeCompte wrote:
>
>
>
>>Hello Kathy,
>>
>>Thank you for your response on the mailing list. I was actually able
>>to solve this problem by setting the Call.SOAPACTION_URI_PROPERTY
>>property correctly in my DII client application. However, I have
>>another question that you may be able to help me out with. I'm a bit
>>confused on when I should use the "-f:wsi" feature for the wscompile
>>utility. I have been using the "-f:documentliteral" feature with
>>wscompile to generate a WSDL file that will work with .NET, etc. Is it
>>true that I only need "-f:wsi" if I want to generate JAX-RPC
>>stubs/ties on the server-side that are WSI 1.0 compliant? It appears
>>that the WSDL file that is produced when I use BOTH the -f:wsi and
>>-f:documentliteral features is exactly the same as if I just use only
>>the -f:documentliteral feature. I have been using only the
>>-f:documentliteral (and not -f:wsi) for generating all of my
>>client/server stubs/ties as well as the seralizers used by the DII
>>client, and I haven't had any trouble accessing my JAX-RPC or .NET web
>>service implementation that is based on the same WSDL produced by
>>using just -f:documentliteral. Also, .NET doesn't complain that the
>>generated WSDL isn't WSI 1.0 compliant. Is there something that I'm
>>missing here? Am I okay with not using the -f:wsi feature? Note that
>>I am also generating my server side web service implementation based
>>on the generated WSDL from passing only -f:documentliteral to
>>wscompile (as opposed to building the server side implementation from
>>the Java endpoint interface).
>>
>>Thank you,
>>
>>-- Ryan
>>
>>----------------------------------------------------------------------
>>--
>>From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com]
>>Sent: Wednesday, October 27, 2004 2:17 PM
>>To: 'users_at_jax-rpc.dev.java.net'
>>Subject: DII client accessing .NET web service
>>
>>Hello,
>>
>>I'm attempting to access a .NET web service using document/literal via
>>a DII client in JAX-RPC (JWSDP 1.4). I'm using the
>>Call.invokeOneWay() method, everything appears to be sent correctly
>>(there are no exceptions thrown in any of the DII client code).
>>However, the request never seems to get to the .NET side. Are there
>>any known issues with DII and .NET? Note that the DII client works
>>fine when the web service is implemented with JAX-RPC and running in
>>the Tomcat 5.0 web container.
>>
>>Thank you,
>>-- Ryan
>>
>>
>>
>
>
>---------------------------------------------------------------------
>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
>
>
>---------------------------------------------------------------------
>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