Doug,
When I use the -f:wsi and the -f:documentliteral together to produce the
WSDL, I don't see any difference in the content of the generated WSDL
compared to a generated WSDL when just the -f:documentliteral option is
specified (and not the -f:wsi). Does this imply that the -f:documentliteral
option causes a WSI 1.0 compliant WSDL to be generated? I guess I'm
struggling with the fact that it doesn't seem that I need the -f:wsi option
when going from a WSDL or a Java interface since -f:documentliteral appears
to generate a WSI 1.0 compliant WSDL, and I can generated a .NET as well as
JAX-RPC web service implementation using that WSDL without any problems. I
just wanted to be sure that NOT using the -f:wsi option was not making my
WSDL non-WSI 1.0 compliant, etc.
-- Ryan
-----Original Message-----
From: Doug Kohlert [mailto:Doug.Kohlert_at_Sun.COM]
Sent: Friday, October 29, 2004 1:48 PM
To: users_at_jax-rpc.dev.java.net
Subject: Re: DII client accessing .NET web service
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
---------------------------------------------------------------------
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