Hi Richard,
The BeanSerializer uses the property name as the element name. One solution
to your problem would be to specify your own BeanInfo class. That BeanInfo
could return whatever property names you want.
Thanks,
-Matt
> -----Original Message-----
> From: Richard S Hendershot [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 5:22 PM
> To: [EMAIL PROTECTED]
> Subject: case sensitive return type
>
>
>
> is it possible to make the return type Upper case?
>
> <return xsi:type="ns1:OrderID"> <orderID
> xsi:type="xsd:string">123456789A</orderID> </return>
>
> ..where I would like 'OrderID' to reflect the return object type
> as well as
> the runtime value? Like so:
> <return xsi:type="ns1:OrderID"> <OrderID
> xsi:type="xsd:string">123456789A</OrderID> </return>
>
> I'm using BeanSerializer and mapping:
> ...Constants.NS_URI_SOAP_ENC, new QName("[snip]","OrderID")...
>
> It's working, ok, but is not quite to the specification I was
> given for our
> application.
>
>
> Thanks in Advance!
> -rsh
>
>
> -----Original Message-----
> From: Martin Gudgin [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 9:41 AM
> To: [EMAIL PROTECTED]
> Subject: XML Protocol: Proposals to address SOAPAction header
>
>
> The W3C XML Protocol Working Group is attempting to address perceived and
> reported problems with the "SOAPAction" mechanism in the HTTP
> binding ( see
> SOAP 1.1 Section 6.1.1 [1] ). As part of this process, the WG wishes to
> solicit
> comments and guidance on two proposals it has generated, as below.
>
> Comments must go to [EMAIL PROTECTED] by 2001-06-18, and should address
> the proposals as they sit, and may optionally make general comments on
> resolution of issues with SOAPAction. Those representing the positions of
> particular groups or organizations are requested to clearly identify
> themselves as such. The WG encourages additional discussion on the
> [EMAIL PROTECTED]
> mailing list.
>
> Neither of the following options precludes equivalent functionality
> elsewhere.
>
> Proposal A:
> Use of SOAPAction is discouraged. SOAPAction is an optional part of XMLP,
> supported but not required. Services MAY require SOAPAction and any
> software wishing to access those services MUST be able to send it.
>
> Proposal B:
> Use of SOAPAction is deprecated. Senders SHOULD NOT send SOAPAction.
> Receivers MUST NOT accept or reject messages on the basis of the presence,
> absence, or value of the SOAPAction header.
>
> Regards
>
> Martin Gudgin
> For the W3C XML Protocol Working Group
>
> [1] http://www.w3.org/TR/SOAP/#_Toc478383528
>
>
>
>
>
>
>
>
