users@jax-rpc.java.net

RE: Re: Using unbounded sequences

From: Steve Pruitt <SPruitt_at_exstream.com>
Date: Sat, 20 Mar 2004 10:12:29 -0500

Anne and Doug,

Thanks for your thoughtful replies. Yes, I can use a static stub. I thought attachments worked in DII if you used INOUT parameters and holder classes. However since I cannot get this to work; I certainly cannot argue they do.

I have looked around for some good examples / hints using document literal style with attachments and JAX-RPC. There seems to be a dearth, most concentrate on rpc style. If anyone can point me to some decent examples I would be grateful.


-Steve


Steve,
The current DII was designed to be uses really with rpc/encoded
endpoints. When JAXRPC 1.0 was specified, it was believed that
rpc/encoding was the way to go. Since then we have learned that
doc/literal or rpc/literal are the better chioices. JAXRPC 2.0 will
define an new DII interface that is better suitted for DII. Although
you can use the current DII to do doc/lit, it really can only be uses
with very simple types. Also, attachments are not supported in DII.
Is there any reason that you cannot use a static stub?

Steve Pruitt wrote:

>The question "why would you want to use rpc/encoded" is beginning to resonate with me. I definitely want to avoid it, it has made life hard. The "rpc" part of jax-rpc is what confused me. It made me think in terms of rpc style operations.
>
>It finally struck me that document / literal is what I want to do, I am not sure how. I need to pass an xml document to my service and the service needs to return a different xml along with a byte []. The document / literal style looks like it handles the xml in and xml out part, but I then need to find someway to make the byte[] an attachment. My client uses DII and its not obvious to me how to implement this scenario using DII. Am I right that document / literal gets me closer to what I need?
>
>
>-SP
>
>
>Doug's right in that if you want to use SOAP encoding, you need to use a
>SOAP encoding array type.
>
>Please note, though, that this is a valid schema structure, and this is how
>you should define an array when using literal encoding.
>
>If you can't change your schema, then you must use literal encoding. For
>best interoperability, you should use doc/literal.
>
>My question is why would you want to use rpc/encoded. It is something to avoid.
>
>Anne
>
>At 04:27 PM 3/19/2004, you wrote:
>
>
>>Christof,
>>Where did you get this WSDL from? I am not sure it is valid. I am pretty
>>sure that soap encoding requires the use of soap-encoded arrays.. There
>>is no work around for this type of WSDL.
>>
>>Christof Strack wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I build a web service which uses as a value type the following type:
>>> <xsd:complexType name="TroubleTicketValueType">
>>> <xsd:sequence>
>>> <xsd:element name="value" type="xsd:string"
>>>minOccurs="1" maxOccurs="unbounded"/>
>>> </xsd:sequence>
>>> </xsd:complexType>
>>>When I process this with wscompile (rpc/encoded) I get an error message
>>>that this type is not supported.
>>>>From the mailing list I've seen one option is to convert the sequence to
>>>an array. This is not an option for me since the schema has to stay
>>>fixed (compatability).
>>>What other options do I have? Is it possible to use JAXB together with
>>>JAX-RPC but still use rpc/encoded style?
>>>
>>>Regards Christof
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>>>
>>>
>>>
>>--
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>Doug Kohlert
>>
>>Sun Microsystems, Inc.
>>503-345-9806
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>NOTICE: This email message is for the sole use of the intended
>>recipient(s) and may contain confidential and privileged
>>information. Any unauthorized review, use, disclosure or
>>distribution is prohibited. If you are not the intended
>>recipient, please contact the sender by reply email and destroy
>>all copies of the original message.
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>>
>>
>
>~~~~~~~~~~~~~~~~~~
>Anne Thomas Manes
>VP & Research Director
>Burton Group
>
>
>---------------------------------------------------------------------
>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
>
>
>
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Doug Kohlert
Sun Microsystems, Inc.            
503-345-9806  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
---------------------------------------------------------------------
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