You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/09/02 16:41:13 UTC
Re: Wrapper style test in WSDL processing?
On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
>
>
>
> On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> >
> > Hi,
> >
> > The operation.getInput() cannot be null to qualify for the wrapper
> > style.
> > There must be a part in the input message corresponding to the operation
> > name:
> >
> > input
> > --- message
> > --- part (only one part)
> > --- element (the element name should be the same as the
> > operation name)
> >
> > The element should look like this:
> >
> > <element name="myMethod">
> > <complexType>
> > <sequence/> <!-- an empty sequence -->
> > </complexType>
> > </element>
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Simon Laws" <si...@googlemail.com>
> > To: "tuscany-dev" <tu...@ws.apache.org>
> > Sent: Friday, August 31, 2007 10:34 AM
> > Subject: Wrapper style test in WSDL processing?
> >
> >
> > > There is a test to determine whether a WSDL operation follows the
> > > "wrapped"
> > > style in accordance with JAX-WS 2.0 spec. See
> > > WSDLOperationIntrospectorImpl
> > > (
> > >
> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> > > )
> > >
> > > The code is currently
> > >
> > > public boolean isWrapperStyle() throws InvalidWSDLException {
> > > if (wrapperStyle == null) {
> > > wrapperStyle =
> > > wrapper.getInputChildElements() != null && (
> > > operation.getOutput() == null || wrapper
> > > .getOutputChildElements() != null);
> > > }
> > > return wrapperStyle;
> > > }
> > >
> > > Which doesn't seem to cater for the case where there may be no input
> > > parameters. I'm diving into this code now to see if I can work out
> > what it
> > > means but if anyone has any insight I would appreciate it.
> > >
> > > Needless to say I have a scenario where I am trying to auto generate
> > WSDL
> > > for a method with the signature
> > >
> > > String myMethod()
> > >
> > > And it's complaining that it's not wrapped.
> > >
> > > Simon
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > What you are saying sounds right to me, I.e. you can validly have no
> parameters in your method but in this case it should build an empty sequence
>
>
> <element name="myMethod">
> <complexType>
> <sequence/> <!-- an empty sequence -->
> </complexType>
> </element>
>
> And have this as the single input type. I'm deeper into the code now
> looking for why this isn't the case.
>
> Thanks Raymond
>
> Simon
>
I've done a bit more investigation now. For the signature
String foo()
Axis2 Java2WSDL generates
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://test/xsd">
<xs:element name="fooResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" nillable="true"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="fooMessage" />
<wsdl:message name="fooResponseMessage">
<wsdl:part name="part1" element="ns:fooResponse" />
</wsdl:message>
So in our code when it comes to testing for wrapped it returns false because
this doesn't match the algorithm that was presented earlier in this thread,
i.e. there is no part of the input message corresponding to the message
name. So when you try this in Tuscany is throws an exception saying that the
operation is not wrapped.
It would be inconvenient for us to not support operations with no
parameters. As the wsdl generation process assumes that the target
operations will be generated as wrapped operations here's what I did..
1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl) to
read.
public boolean isWrapperStyle() throws InvalidWSDLException {
if (wrapperStyle == null) {
wrapperStyle =
(operation.getInput().getMessage().getParts().values().size()
== 0 ||wrapper.getInputChildElements() != null) &&
(operation.getOutput() == null ||
wrapper.getOutputChildElements() != null);
}
return wrapperStyle;
}
I.e. I'm letting it pass if there are no input parts at all which I believe
is valid according the the JAX-WS 2.0 spec
2/ Fixed the getWrapperInfo method to take account of the case where there
are no input params
if (in != null) {
for (XmlSchemaElement e : getInputChildElements()) {
inChildren.add(getElementInfo(e));
}
}
3/ Fixed the Axis2 binding to properly deal with the case when no parameters
are present in Axis2ServiceInOutSyncMessageReceiver.
public void invokeBusinessLogic(MessageContext inMC, MessageContext
outMC) throws AxisFault {
try {
OMElement requestOM = inMC.getEnvelope
().getBody().getFirstElement();
Object[] args = null;
if (requestOM != null) {
args = new Object[] {requestOM};
}
The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
This works with the forward message relying on the soap action to indentify
the correct operation.
I haven't checked this in as the code seems to have been carefully crafted
to assume that there will always be an input parameter. Can someone explain
why this is thought to be the case?
Regards
Simon
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/5/07, ant elder <an...@gmail.com> wrote:
>
> On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > >
> > >
> > > On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > The operation.getInput() cannot be null to qualify for the wrapper
> > > > style.
> > > > There must be a part in the input message corresponding to the
> > operation
> > > > name:
> > > >
> > > > input
> > > > --- message
> > > > --- part (only one part)
> > > > --- element (the element name should be the same as
> > the
> > > > operation name)
> > > >
> > > > The element should look like this:
> > > >
> > > > <element name="myMethod">
> > > > <complexType>
> > > > <sequence/> <!-- an empty sequence -->
> > > > </complexType>
> > > > </element>
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > ----- Original Message -----
> > > > From: "Simon Laws" <si...@googlemail.com>
> > > > To: "tuscany-dev" <tu...@ws.apache.org>
> > > > Sent: Friday, August 31, 2007 10:34 AM
> > > > Subject: Wrapper style test in WSDL processing?
> > > >
> > > >
> > > > > There is a test to determine whether a WSDL operation follows the
> > > > > "wrapped"
> > > > > style in accordance with JAX-WS 2.0 spec. See
> > > > > WSDLOperationIntrospectorImpl
> > > > > (
> > > > >
> > > >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> > > > > )
> > > > >
> > > > > The code is currently
> > > > >
> > > > > public boolean isWrapperStyle() throws InvalidWSDLException {
> > > > > if (wrapperStyle == null) {
> > > > > wrapperStyle =
> > > > > wrapper.getInputChildElements() != null && (
> > > > > operation.getOutput() == null || wrapper
> > > > > .getOutputChildElements() != null);
> > > > > }
> > > > > return wrapperStyle;
> > > > > }
> > > > >
> > > > > Which doesn't seem to cater for the case where there may be no
> input
> > > > > parameters. I'm diving into this code now to see if I can work out
> > > > what it
> > > > > means but if anyone has any insight I would appreciate it.
> > > > >
> > > > > Needless to say I have a scenario where I am trying to auto
> generate
> > > > WSDL
> > > > > for a method with the signature
> > > > >
> > > > > String myMethod()
> > > > >
> > > > > And it's complaining that it's not wrapped.
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > > What you are saying sounds right to me, I.e. you can validly have no
> > > parameters in your method but in this case it should build an empty
> > sequence
> > >
> > >
> > > <element name="myMethod">
> > > <complexType>
> > > <sequence/> <!-- an empty sequence -->
> > > </complexType>
> > > </element>
> > >
> > > And have this as the single input type. I'm deeper into the code now
> > > looking for why this isn't the case.
> > >
> > > Thanks Raymond
> > >
> > > Simon
> > >
> > I've done a bit more investigation now. For the signature
> >
> > String foo()
> >
> > Axis2 Java2WSDL generates
> >
> > <wsdl:types>
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > attributeFormDefault="qualified"
> > elementFormDefault="qualified"
> > targetNamespace="http://test/xsd">
> > <xs:element name="fooResponse">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="return" nillable="true"
> > type="xs:string" />
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> > </xs:schema>
> > </wsdl:types>
> > <wsdl:message name="fooMessage" />
> > <wsdl:message name="fooResponseMessage">
> > <wsdl:part name="part1" element="ns:fooResponse" />
> > </wsdl:message>
> >
> > So in our code when it comes to testing for wrapped it returns false
> > because
> > this doesn't match the algorithm that was presented earlier in this
> > thread,
> > i.e. there is no part of the input message corresponding to the message
> > name. So when you try this in Tuscany is throws an exception saying that
> > the
> > operation is not wrapped.
> >
> > It would be inconvenient for us to not support operations with no
> > parameters. As the wsdl generation process assumes that the target
> > operations will be generated as wrapped operations here's what I did..
> >
> > 1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
> to
> > read.
> >
> > public boolean isWrapperStyle() throws InvalidWSDLException {
> > if (wrapperStyle == null) {
> > wrapperStyle =
> > (operation.getInput
> > ().getMessage().getParts().values().size()
> > == 0 ||wrapper.getInputChildElements() != null) &&
> > (operation.getOutput() == null ||
> > wrapper.getOutputChildElements() != null);
> > }
> > return wrapperStyle;
> > }
> >
> > I.e. I'm letting it pass if there are no input parts at all which I
> > believe
> > is valid according the the JAX-WS 2.0 spec
> >
> > 2/ Fixed the getWrapperInfo method to take account of the case where
> there
> > are no input params
> >
> > if (in != null) {
> > for (XmlSchemaElement e : getInputChildElements()) {
> > inChildren.add(getElementInfo(e));
> > }
> > }
> >
> > 3/ Fixed the Axis2 binding to properly deal with the case when no
> > parameters
> > are present in Axis2ServiceInOutSyncMessageReceiver.
> >
> > public void invokeBusinessLogic(MessageContext inMC, MessageContext
> > outMC) throws AxisFault {
> > try {
> > OMElement requestOM = inMC.getEnvelope
> > ().getBody().getFirstElement();
> > Object[] args = null;
> >
> > if (requestOM != null) {
> > args = new Object[] {requestOM};
> > }
> >
> > The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
> >
> > This works with the forward message relying on the soap action to
> > indentify
> > the correct operation.
> >
> > I haven't checked this in as the code seems to have been carefully
> crafted
> > to assume that there will always be an input parameter. Can someone
> > explain
> > why this is thought to be the case?
>
>
> If there's no objections very soon then how about just doing this fix for
> now so Tuscany tolerates the Axis2 way for now (and something similar for
> TUSCANY-1658)?
>
> ...ant
>
I have the fix for the null parameter case sitting here on my pc so I'll
commit it later if no one shouts.
Simon
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
I agree that interoperability is important, not just with Axis2 but
also with other Web Service stacks out there.
The best guide to industry standard Web Service interoperability
that I am aware of is the WS-I Basic Profile.
If we send an empty body in the case of a no-argument Java method
(as this form of WSDL would imply), and if more than one method on a
service interface can have a no-argument signature, then this would
violate the following requirement for WS-I interoperabilty:
R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result
in operation signatures that are different from one another.
If we (or the Axis2 runtime) rely on the soap:action to disambiguate
these operations (as was suggested in a previous post to this thread),
then this would violate the following WS-I requirement:
R1127 A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP
header to correctly process the message. [SOAP12]
However if we are using WS-Addressing then it would be valid from a
WS-I perspective to use wsa:Action to disambiguate the operations.
We are using parts of WS-Addressing but I don't think we are currently
fully compliant.
I'm doing further investigation into how Axis2 disambiguates the case
of two different service operations without arguments that are both
mapped to an empty body in the SOAP message. If anyone can give me a
pointer to the relevant code, it would be much appreciated.
Simon
ant elder wrote:
> But doesn't that mean we're not going to work with wsdl generated by Axis2
> tooling (and likely others) and all the existing services using that wsdl
> and returning it with ?wsdl.
>
> Its even debatable the wsdl is "wrong" as wrapped style has been used long
> before jaxws came along but never precisely defined in any spec. I'd still
> prefer we just make Tuscany tolerant of it than try to fiddle about changing
> the wsdl that people are trying to use.
>
> ...ant
>
> On 9/5/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>>I have concerns about making the Tuscany code wrong to compensate for
>>the generated WSDL being wrong. This feels like a step in the wrong
>>direction, and it won't allow non-Tuscany Web service clients to call
>>Tuscany services that use generated WSDL.
>>
>>Instead, I'd prefer to have Tuscany postprocess the incorrect
>>WSDLDefinition returned by the Axis2 generator and fix it up so that
>>it's correct. The seems much cleaner and more robust that having
>>Tuscany override parts of the Axis2 generator code. If in future
>>the Axis2 code returns a correct WSDLDefinition, then the Tuscany
>>postprocessor can just pass it through unchanged.
>>
>>I am willing to take on the task of implementing this.
>>
>> Simon
>>
>>ant elder wrote:
>>
>>
>>>On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>
>>>>On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
>>>>
>>>>
>>>>>
>>>>>On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>The operation.getInput() cannot be null to qualify for the wrapper
>>>>>>style.
>>>>>>There must be a part in the input message corresponding to the
>>>>
>>>>operation
>>>>
>>>>
>>>>>>name:
>>>>>>
>>>>>>input
>>>>>> --- message
>>>>>> --- part (only one part)
>>>>>> --- element (the element name should be the same as
>>>>
>>>>the
>>>>
>>>>
>>>>>>operation name)
>>>>>>
>>>>>>The element should look like this:
>>>>>>
>>>>>><element name="myMethod">
>>>>>> <complexType>
>>>>>> <sequence/> <!-- an empty sequence -->
>>>>>> </complexType>
>>>>>></element>
>>>>>>
>>>>>>Thanks,
>>>>>>Raymond
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "Simon Laws" <si...@googlemail.com>
>>>>>>To: "tuscany-dev" <tu...@ws.apache.org>
>>>>>>Sent: Friday, August 31, 2007 10:34 AM
>>>>>>Subject: Wrapper style test in WSDL processing?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>There is a test to determine whether a WSDL operation follows the
>>>>>>>"wrapped"
>>>>>>>style in accordance with JAX-WS 2.0 spec. See
>>>>>>>WSDLOperationIntrospectorImpl
>>>>>>>(
>>>>>>>
>>>>>>
>>http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
>>
>>>>>>>)
>>>>>>>
>>>>>>>The code is currently
>>>>>>>
>>>>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
>>>>>>> if (wrapperStyle == null) {
>>>>>>> wrapperStyle =
>>>>>>> wrapper.getInputChildElements() != null && (
>>>>>>>operation.getOutput() == null || wrapper
>>>>>>> .getOutputChildElements() != null);
>>>>>>> }
>>>>>>> return wrapperStyle;
>>>>>>> }
>>>>>>>
>>>>>>>Which doesn't seem to cater for the case where there may be no input
>>>>>>>parameters. I'm diving into this code now to see if I can work out
>>>>>>
>>>>>>what it
>>>>>>
>>>>>>
>>>>>>>means but if anyone has any insight I would appreciate it.
>>>>>>>
>>>>>>>Needless to say I have a scenario where I am trying to auto generate
>>>>>>
>>>>>>WSDL
>>>>>>
>>>>>>
>>>>>>>for a method with the signature
>>>>>>>
>>>>>>>String myMethod()
>>>>>>>
>>>>>>>And it's complaining that it's not wrapped.
>>>>>>>
>>>>>>>Simon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>>What you are saying sounds right to me, I.e. you can validly have no
>>>>>
>>>>>parameters in your method but in this case it should build an empty
>>>>
>>>>sequence
>>>>
>>>>
>>>>><element name="myMethod">
>>>>> <complexType>
>>>>> <sequence/> <!-- an empty sequence -->
>>>>> </complexType>
>>>>></element>
>>>>>
>>>>>And have this as the single input type. I'm deeper into the code now
>>>>>looking for why this isn't the case.
>>>>>
>>>>>Thanks Raymond
>>>>>
>>>>>Simon
>>>>>
>>>>
>>>>I've done a bit more investigation now. For the signature
>>>>
>>>>String foo()
>>>>
>>>>Axis2 Java2WSDL generates
>>>>
>>>> <wsdl:types>
>>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>> attributeFormDefault="qualified"
>>>>elementFormDefault="qualified"
>>>> targetNamespace="http://test/xsd">
>>>> <xs:element name="fooResponse">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="return" nillable="true"
>>>> type="xs:string" />
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:schema>
>>>> </wsdl:types>
>>>> <wsdl:message name="fooMessage" />
>>>> <wsdl:message name="fooResponseMessage">
>>>> <wsdl:part name="part1" element="ns:fooResponse" />
>>>> </wsdl:message>
>>>>
>>>>So in our code when it comes to testing for wrapped it returns false
>>>>because
>>>>this doesn't match the algorithm that was presented earlier in this
>>>>thread,
>>>>i.e. there is no part of the input message corresponding to the message
>>>>name. So when you try this in Tuscany is throws an exception saying that
>>>>the
>>>>operation is not wrapped.
>>>>
>>>>It would be inconvenient for us to not support operations with no
>>>>parameters. As the wsdl generation process assumes that the target
>>>>operations will be generated as wrapped operations here's what I did..
>>>>
>>>>1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
>>
>>to
>>
>>>>read.
>>>>
>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
>>>> if (wrapperStyle == null) {
>>>> wrapperStyle =
>>>> (operation.getInput
>>>>().getMessage().getParts().values().size()
>>>>== 0 ||wrapper.getInputChildElements() != null) &&
>>>> (operation.getOutput() == null ||
>>>>wrapper.getOutputChildElements() != null);
>>>> }
>>>> return wrapperStyle;
>>>> }
>>>>
>>>>I.e. I'm letting it pass if there are no input parts at all which I
>>>>believe
>>>>is valid according the the JAX-WS 2.0 spec
>>>>
>>>>2/ Fixed the getWrapperInfo method to take account of the case where
>>
>>there
>>
>>>>are no input params
>>>>
>>>> if (in != null) {
>>>> for (XmlSchemaElement e : getInputChildElements()) {
>>>> inChildren.add(getElementInfo(e));
>>>> }
>>>> }
>>>>
>>>>3/ Fixed the Axis2 binding to properly deal with the case when no
>>>>parameters
>>>>are present in Axis2ServiceInOutSyncMessageReceiver.
>>>>
>>>> public void invokeBusinessLogic(MessageContext inMC, MessageContext
>>>>outMC) throws AxisFault {
>>>> try {
>>>> OMElement requestOM = inMC.getEnvelope
>>>>().getBody().getFirstElement();
>>>> Object[] args = null;
>>>>
>>>> if (requestOM != null) {
>>>> args = new Object[] {requestOM};
>>>> }
>>>>
>>>>The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
>>>>
>>>>This works with the forward message relying on the soap action to
>>>>indentify
>>>>the correct operation.
>>>>
>>>>I haven't checked this in as the code seems to have been carefully
>>
>>crafted
>>
>>>>to assume that there will always be an input parameter. Can someone
>>>>explain
>>>>why this is thought to be the case?
>>>
>>>
>>>
>>>If there's no objections very soon then how about just doing this fix
>>
>>for
>>
>>>now so Tuscany tolerates the Axis2 way for now (and something similar
>>
>>for
>>
>>>TUSCANY-1658)?
>>>
>>> ...ant
>>>
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by ant elder <an...@gmail.com>.
But doesn't that mean we're not going to work with wsdl generated by Axis2
tooling (and likely others) and all the existing services using that wsdl
and returning it with ?wsdl.
Its even debatable the wsdl is "wrong" as wrapped style has been used long
before jaxws came along but never precisely defined in any spec. I'd still
prefer we just make Tuscany tolerant of it than try to fiddle about changing
the wsdl that people are trying to use.
...ant
On 9/5/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> I have concerns about making the Tuscany code wrong to compensate for
> the generated WSDL being wrong. This feels like a step in the wrong
> direction, and it won't allow non-Tuscany Web service clients to call
> Tuscany services that use generated WSDL.
>
> Instead, I'd prefer to have Tuscany postprocess the incorrect
> WSDLDefinition returned by the Axis2 generator and fix it up so that
> it's correct. The seems much cleaner and more robust that having
> Tuscany override parts of the Axis2 generator code. If in future
> the Axis2 code returns a correct WSDLDefinition, then the Tuscany
> postprocessor can just pass it through unchanged.
>
> I am willing to take on the task of implementing this.
>
> Simon
>
> ant elder wrote:
>
> > On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >>On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >>>
> >>>
> >>>On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>The operation.getInput() cannot be null to qualify for the wrapper
> >>>>style.
> >>>>There must be a part in the input message corresponding to the
> >>
> >>operation
> >>
> >>>>name:
> >>>>
> >>>>input
> >>>> --- message
> >>>> --- part (only one part)
> >>>> --- element (the element name should be the same as
> >>
> >>the
> >>
> >>>>operation name)
> >>>>
> >>>>The element should look like this:
> >>>>
> >>>><element name="myMethod">
> >>>> <complexType>
> >>>> <sequence/> <!-- an empty sequence -->
> >>>> </complexType>
> >>>></element>
> >>>>
> >>>>Thanks,
> >>>>Raymond
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Simon Laws" <si...@googlemail.com>
> >>>>To: "tuscany-dev" <tu...@ws.apache.org>
> >>>>Sent: Friday, August 31, 2007 10:34 AM
> >>>>Subject: Wrapper style test in WSDL processing?
> >>>>
> >>>>
> >>>>
> >>>>>There is a test to determine whether a WSDL operation follows the
> >>>>>"wrapped"
> >>>>>style in accordance with JAX-WS 2.0 spec. See
> >>>>>WSDLOperationIntrospectorImpl
> >>>>>(
> >>>>>
> >>>>
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> >>
> >>>>>)
> >>>>>
> >>>>>The code is currently
> >>>>>
> >>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
> >>>>> if (wrapperStyle == null) {
> >>>>> wrapperStyle =
> >>>>> wrapper.getInputChildElements() != null && (
> >>>>>operation.getOutput() == null || wrapper
> >>>>> .getOutputChildElements() != null);
> >>>>> }
> >>>>> return wrapperStyle;
> >>>>> }
> >>>>>
> >>>>>Which doesn't seem to cater for the case where there may be no input
> >>>>>parameters. I'm diving into this code now to see if I can work out
> >>>>
> >>>>what it
> >>>>
> >>>>>means but if anyone has any insight I would appreciate it.
> >>>>>
> >>>>>Needless to say I have a scenario where I am trying to auto generate
> >>>>
> >>>>WSDL
> >>>>
> >>>>>for a method with the signature
> >>>>>
> >>>>>String myMethod()
> >>>>>
> >>>>>And it's complaining that it's not wrapped.
> >>>>>
> >>>>>Simon
> >>>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>>What you are saying sounds right to me, I.e. you can validly have no
> >>>
> >>>parameters in your method but in this case it should build an empty
> >>
> >>sequence
> >>
> >>>
> >>><element name="myMethod">
> >>> <complexType>
> >>> <sequence/> <!-- an empty sequence -->
> >>> </complexType>
> >>></element>
> >>>
> >>>And have this as the single input type. I'm deeper into the code now
> >>>looking for why this isn't the case.
> >>>
> >>>Thanks Raymond
> >>>
> >>>Simon
> >>>
> >>
> >>I've done a bit more investigation now. For the signature
> >>
> >>String foo()
> >>
> >>Axis2 Java2WSDL generates
> >>
> >> <wsdl:types>
> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >> attributeFormDefault="qualified"
> >>elementFormDefault="qualified"
> >> targetNamespace="http://test/xsd">
> >> <xs:element name="fooResponse">
> >> <xs:complexType>
> >> <xs:sequence>
> >> <xs:element name="return" nillable="true"
> >> type="xs:string" />
> >> </xs:sequence>
> >> </xs:complexType>
> >> </xs:element>
> >> </xs:schema>
> >> </wsdl:types>
> >> <wsdl:message name="fooMessage" />
> >> <wsdl:message name="fooResponseMessage">
> >> <wsdl:part name="part1" element="ns:fooResponse" />
> >> </wsdl:message>
> >>
> >>So in our code when it comes to testing for wrapped it returns false
> >>because
> >>this doesn't match the algorithm that was presented earlier in this
> >>thread,
> >>i.e. there is no part of the input message corresponding to the message
> >>name. So when you try this in Tuscany is throws an exception saying that
> >>the
> >>operation is not wrapped.
> >>
> >>It would be inconvenient for us to not support operations with no
> >>parameters. As the wsdl generation process assumes that the target
> >>operations will be generated as wrapped operations here's what I did..
> >>
> >>1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
> to
> >>read.
> >>
> >> public boolean isWrapperStyle() throws InvalidWSDLException {
> >> if (wrapperStyle == null) {
> >> wrapperStyle =
> >> (operation.getInput
> >>().getMessage().getParts().values().size()
> >>== 0 ||wrapper.getInputChildElements() != null) &&
> >> (operation.getOutput() == null ||
> >>wrapper.getOutputChildElements() != null);
> >> }
> >> return wrapperStyle;
> >> }
> >>
> >>I.e. I'm letting it pass if there are no input parts at all which I
> >>believe
> >>is valid according the the JAX-WS 2.0 spec
> >>
> >>2/ Fixed the getWrapperInfo method to take account of the case where
> there
> >>are no input params
> >>
> >> if (in != null) {
> >> for (XmlSchemaElement e : getInputChildElements()) {
> >> inChildren.add(getElementInfo(e));
> >> }
> >> }
> >>
> >>3/ Fixed the Axis2 binding to properly deal with the case when no
> >>parameters
> >>are present in Axis2ServiceInOutSyncMessageReceiver.
> >>
> >> public void invokeBusinessLogic(MessageContext inMC, MessageContext
> >>outMC) throws AxisFault {
> >> try {
> >> OMElement requestOM = inMC.getEnvelope
> >>().getBody().getFirstElement();
> >> Object[] args = null;
> >>
> >> if (requestOM != null) {
> >> args = new Object[] {requestOM};
> >> }
> >>
> >>The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
> >>
> >>This works with the forward message relying on the soap action to
> >>indentify
> >>the correct operation.
> >>
> >>I haven't checked this in as the code seems to have been carefully
> crafted
> >>to assume that there will always be an input parameter. Can someone
> >>explain
> >>why this is thought to be the case?
> >
> >
> >
> > If there's no objections very soon then how about just doing this fix
> for
> > now so Tuscany tolerates the Axis2 way for now (and something similar
> for
> > TUSCANY-1658)?
> >
> > ...ant
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/5/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> +1 to doing the fixup in one place, and rationalizing all the
> places where we generate WSDL. I'd appreciate some pointers to
> where these are as I don't think I've found them all yet :-)
>
> Simon
>
> Simon Laws wrote:
>
> > On 9/5/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> >>I have concerns about making the Tuscany code wrong to compensate for
> >>the generated WSDL being wrong. This feels like a step in the wrong
> >>direction, and it won't allow non-Tuscany Web service clients to call
> >>Tuscany services that use generated WSDL.
> >>
> >>Instead, I'd prefer to have Tuscany postprocess the incorrect
> >>WSDLDefinition returned by the Axis2 generator and fix it up so that
> >>it's correct. The seems much cleaner and more robust that having
> >>Tuscany override parts of the Axis2 generator code. If in future
> >>the Axis2 code returns a correct WSDLDefinition, then the Tuscany
> >>postprocessor can just pass it through unchanged.
> >>
> >>I am willing to take on the task of implementing this.
> >>
> >> Simon
> >>
> >>ant elder wrote:
> >>
> >>
> >>>On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
> >>>
> >>>
> >>>>On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> >>>>
> >>>>
> >>>>>
> >>>>>On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>The operation.getInput() cannot be null to qualify for the wrapper
> >>>>>>style.
> >>>>>>There must be a part in the input message corresponding to the
> >>>>
> >>>>operation
> >>>>
> >>>>
> >>>>>>name:
> >>>>>>
> >>>>>>input
> >>>>>> --- message
> >>>>>> --- part (only one part)
> >>>>>> --- element (the element name should be the same as
> >>>>
> >>>>the
> >>>>
> >>>>
> >>>>>>operation name)
> >>>>>>
> >>>>>>The element should look like this:
> >>>>>>
> >>>>>><element name="myMethod">
> >>>>>> <complexType>
> >>>>>> <sequence/> <!-- an empty sequence -->
> >>>>>> </complexType>
> >>>>>></element>
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Raymond
> >>>>>>
> >>>>>>----- Original Message -----
> >>>>>>From: "Simon Laws" <si...@googlemail.com>
> >>>>>>To: "tuscany-dev" <tu...@ws.apache.org>
> >>>>>>Sent: Friday, August 31, 2007 10:34 AM
> >>>>>>Subject: Wrapper style test in WSDL processing?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>There is a test to determine whether a WSDL operation follows the
> >>>>>>>"wrapped"
> >>>>>>>style in accordance with JAX-WS 2.0 spec. See
> >>>>>>>WSDLOperationIntrospectorImpl
> >>>>>>>(
> >>>>>>>
> >>>>>>
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> >>
> >>>>>>>)
> >>>>>>>
> >>>>>>>The code is currently
> >>>>>>>
> >>>>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
> >>>>>>> if (wrapperStyle == null) {
> >>>>>>> wrapperStyle =
> >>>>>>> wrapper.getInputChildElements() != null && (
> >>>>>>>operation.getOutput() == null || wrapper
> >>>>>>> .getOutputChildElements() != null);
> >>>>>>> }
> >>>>>>> return wrapperStyle;
> >>>>>>> }
> >>>>>>>
> >>>>>>>Which doesn't seem to cater for the case where there may be no
> input
> >>>>>>>parameters. I'm diving into this code now to see if I can work out
> >>>>>>
> >>>>>>what it
> >>>>>>
> >>>>>>
> >>>>>>>means but if anyone has any insight I would appreciate it.
> >>>>>>>
> >>>>>>>Needless to say I have a scenario where I am trying to auto
> generate
> >>>>>>
> >>>>>>WSDL
> >>>>>>
> >>>>>>
> >>>>>>>for a method with the signature
> >>>>>>>
> >>>>>>>String myMethod()
> >>>>>>>
> >>>>>>>And it's complaining that it's not wrapped.
> >>>>>>>
> >>>>>>>Simon
> >>>>>>>
> >>>>>>
> >>>>>>
>
> >>>>>>---------------------------------------------------------------------
> >>>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>>
> >>>>>>What you are saying sounds right to me, I.e. you can validly have no
> >>>>>
> >>>>>parameters in your method but in this case it should build an empty
> >>>>
> >>>>sequence
> >>>>
> >>>>
> >>>>><element name="myMethod">
> >>>>> <complexType>
> >>>>> <sequence/> <!-- an empty sequence -->
> >>>>> </complexType>
> >>>>></element>
> >>>>>
> >>>>>And have this as the single input type. I'm deeper into the code now
> >>>>>looking for why this isn't the case.
> >>>>>
> >>>>>Thanks Raymond
> >>>>>
> >>>>>Simon
> >>>>>
> >>>>
> >>>>I've done a bit more investigation now. For the signature
> >>>>
> >>>>String foo()
> >>>>
> >>>>Axis2 Java2WSDL generates
> >>>>
> >>>> <wsdl:types>
> >>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >>>> attributeFormDefault="qualified"
> >>>>elementFormDefault="qualified"
> >>>> targetNamespace="http://test/xsd">
> >>>> <xs:element name="fooResponse">
> >>>> <xs:complexType>
> >>>> <xs:sequence>
> >>>> <xs:element name="return" nillable="true"
> >>>> type="xs:string" />
> >>>> </xs:sequence>
> >>>> </xs:complexType>
> >>>> </xs:element>
> >>>> </xs:schema>
> >>>> </wsdl:types>
> >>>> <wsdl:message name="fooMessage" />
> >>>> <wsdl:message name="fooResponseMessage">
> >>>> <wsdl:part name="part1" element="ns:fooResponse" />
> >>>> </wsdl:message>
> >>>>
> >>>>So in our code when it comes to testing for wrapped it returns false
> >>>>because
> >>>>this doesn't match the algorithm that was presented earlier in this
> >>>>thread,
> >>>>i.e. there is no part of the input message corresponding to the
> message
> >>>>name. So when you try this in Tuscany is throws an exception saying
> that
> >>>>the
> >>>>operation is not wrapped.
> >>>>
> >>>>It would be inconvenient for us to not support operations with no
> >>>>parameters. As the wsdl generation process assumes that the target
> >>>>operations will be generated as wrapped operations here's what I did..
> >>>>
> >>>>1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
> >>
> >>to
> >>
> >>>>read.
> >>>>
> >>>> public boolean isWrapperStyle() throws InvalidWSDLException {
> >>>> if (wrapperStyle == null) {
> >>>> wrapperStyle =
> >>>> (operation.getInput
> >>>>().getMessage().getParts().values().size()
> >>>>== 0 ||wrapper.getInputChildElements() != null) &&
> >>>> (operation.getOutput() == null ||
> >>>>wrapper.getOutputChildElements() != null);
> >>>> }
> >>>> return wrapperStyle;
> >>>> }
> >>>>
> >>>>I.e. I'm letting it pass if there are no input parts at all which I
> >>>>believe
> >>>>is valid according the the JAX-WS 2.0 spec
> >>>>
> >>>>2/ Fixed the getWrapperInfo method to take account of the case where
> >>
> >>there
> >>
> >>>>are no input params
> >>>>
> >>>> if (in != null) {
> >>>> for (XmlSchemaElement e : getInputChildElements())
> {
> >>>> inChildren.add(getElementInfo(e));
> >>>> }
> >>>> }
> >>>>
> >>>>3/ Fixed the Axis2 binding to properly deal with the case when no
> >>>>parameters
> >>>>are present in Axis2ServiceInOutSyncMessageReceiver.
> >>>>
> >>>> public void invokeBusinessLogic(MessageContext inMC, MessageContext
> >>>>outMC) throws AxisFault {
> >>>> try {
> >>>> OMElement requestOM = inMC.getEnvelope
> >>>>().getBody().getFirstElement();
> >>>> Object[] args = null;
> >>>>
> >>>> if (requestOM != null) {
> >>>> args = new Object[] {requestOM};
> >>>> }
> >>>>
> >>>>The Axis2ServiceInMessageReceiver needs the same fix if we go with
> this.
> >>>>
> >>>>This works with the forward message relying on the soap action to
> >>>>indentify
> >>>>the correct operation.
> >>>>
> >>>>I haven't checked this in as the code seems to have been carefully
> >>
> >>crafted
> >>
> >>>>to assume that there will always be an input parameter. Can someone
> >>>>explain
> >>>>why this is thought to be the case?
> >>>
> >>>
> >>>
> >>>If there's no objections very soon then how about just doing this fix
> >>
> >>for
> >>
> >>>now so Tuscany tolerates the Axis2 way for now (and something similar
> >>
> >>for
> >>
> >>>TUSCANY-1658)?
> >>>
> >>> ...ant
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>We seem to be agreeing that patching up the axis generators is no ideal
> >
> >
> > I quite like the sound of fixing up the WSDL after it's generated.
> >
> > We do WSDL generation in several places so we would have to trap them
> > (ideally by rationalizing to use only one set of code if we can)
> >
> > Regards
> >
> > Simon
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> We certainly do in binding-ws-axis2 and java2wsdl. The sca remote binding
calls into ws-axis2 but would need a fix it it's moved. Not sure where ?wsdl
is done. Those are the ones I know about. Luciano and Ant are the experts
here.
Simon
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
+1 to doing the fixup in one place, and rationalizing all the
places where we generate WSDL. I'd appreciate some pointers to
where these are as I don't think I've found them all yet :-)
Simon
Simon Laws wrote:
> On 9/5/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>>I have concerns about making the Tuscany code wrong to compensate for
>>the generated WSDL being wrong. This feels like a step in the wrong
>>direction, and it won't allow non-Tuscany Web service clients to call
>>Tuscany services that use generated WSDL.
>>
>>Instead, I'd prefer to have Tuscany postprocess the incorrect
>>WSDLDefinition returned by the Axis2 generator and fix it up so that
>>it's correct. The seems much cleaner and more robust that having
>>Tuscany override parts of the Axis2 generator code. If in future
>>the Axis2 code returns a correct WSDLDefinition, then the Tuscany
>>postprocessor can just pass it through unchanged.
>>
>>I am willing to take on the task of implementing this.
>>
>> Simon
>>
>>ant elder wrote:
>>
>>
>>>On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
>>>
>>>
>>>>On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
>>>>
>>>>
>>>>>
>>>>>On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>The operation.getInput() cannot be null to qualify for the wrapper
>>>>>>style.
>>>>>>There must be a part in the input message corresponding to the
>>>>
>>>>operation
>>>>
>>>>
>>>>>>name:
>>>>>>
>>>>>>input
>>>>>> --- message
>>>>>> --- part (only one part)
>>>>>> --- element (the element name should be the same as
>>>>
>>>>the
>>>>
>>>>
>>>>>>operation name)
>>>>>>
>>>>>>The element should look like this:
>>>>>>
>>>>>><element name="myMethod">
>>>>>> <complexType>
>>>>>> <sequence/> <!-- an empty sequence -->
>>>>>> </complexType>
>>>>>></element>
>>>>>>
>>>>>>Thanks,
>>>>>>Raymond
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "Simon Laws" <si...@googlemail.com>
>>>>>>To: "tuscany-dev" <tu...@ws.apache.org>
>>>>>>Sent: Friday, August 31, 2007 10:34 AM
>>>>>>Subject: Wrapper style test in WSDL processing?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>There is a test to determine whether a WSDL operation follows the
>>>>>>>"wrapped"
>>>>>>>style in accordance with JAX-WS 2.0 spec. See
>>>>>>>WSDLOperationIntrospectorImpl
>>>>>>>(
>>>>>>>
>>>>>>
>>http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
>>
>>>>>>>)
>>>>>>>
>>>>>>>The code is currently
>>>>>>>
>>>>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
>>>>>>> if (wrapperStyle == null) {
>>>>>>> wrapperStyle =
>>>>>>> wrapper.getInputChildElements() != null && (
>>>>>>>operation.getOutput() == null || wrapper
>>>>>>> .getOutputChildElements() != null);
>>>>>>> }
>>>>>>> return wrapperStyle;
>>>>>>> }
>>>>>>>
>>>>>>>Which doesn't seem to cater for the case where there may be no input
>>>>>>>parameters. I'm diving into this code now to see if I can work out
>>>>>>
>>>>>>what it
>>>>>>
>>>>>>
>>>>>>>means but if anyone has any insight I would appreciate it.
>>>>>>>
>>>>>>>Needless to say I have a scenario where I am trying to auto generate
>>>>>>
>>>>>>WSDL
>>>>>>
>>>>>>
>>>>>>>for a method with the signature
>>>>>>>
>>>>>>>String myMethod()
>>>>>>>
>>>>>>>And it's complaining that it's not wrapped.
>>>>>>>
>>>>>>>Simon
>>>>>>>
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>>
>>>>>>What you are saying sounds right to me, I.e. you can validly have no
>>>>>
>>>>>parameters in your method but in this case it should build an empty
>>>>
>>>>sequence
>>>>
>>>>
>>>>><element name="myMethod">
>>>>> <complexType>
>>>>> <sequence/> <!-- an empty sequence -->
>>>>> </complexType>
>>>>></element>
>>>>>
>>>>>And have this as the single input type. I'm deeper into the code now
>>>>>looking for why this isn't the case.
>>>>>
>>>>>Thanks Raymond
>>>>>
>>>>>Simon
>>>>>
>>>>
>>>>I've done a bit more investigation now. For the signature
>>>>
>>>>String foo()
>>>>
>>>>Axis2 Java2WSDL generates
>>>>
>>>> <wsdl:types>
>>>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>>>> attributeFormDefault="qualified"
>>>>elementFormDefault="qualified"
>>>> targetNamespace="http://test/xsd">
>>>> <xs:element name="fooResponse">
>>>> <xs:complexType>
>>>> <xs:sequence>
>>>> <xs:element name="return" nillable="true"
>>>> type="xs:string" />
>>>> </xs:sequence>
>>>> </xs:complexType>
>>>> </xs:element>
>>>> </xs:schema>
>>>> </wsdl:types>
>>>> <wsdl:message name="fooMessage" />
>>>> <wsdl:message name="fooResponseMessage">
>>>> <wsdl:part name="part1" element="ns:fooResponse" />
>>>> </wsdl:message>
>>>>
>>>>So in our code when it comes to testing for wrapped it returns false
>>>>because
>>>>this doesn't match the algorithm that was presented earlier in this
>>>>thread,
>>>>i.e. there is no part of the input message corresponding to the message
>>>>name. So when you try this in Tuscany is throws an exception saying that
>>>>the
>>>>operation is not wrapped.
>>>>
>>>>It would be inconvenient for us to not support operations with no
>>>>parameters. As the wsdl generation process assumes that the target
>>>>operations will be generated as wrapped operations here's what I did..
>>>>
>>>>1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
>>
>>to
>>
>>>>read.
>>>>
>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
>>>> if (wrapperStyle == null) {
>>>> wrapperStyle =
>>>> (operation.getInput
>>>>().getMessage().getParts().values().size()
>>>>== 0 ||wrapper.getInputChildElements() != null) &&
>>>> (operation.getOutput() == null ||
>>>>wrapper.getOutputChildElements() != null);
>>>> }
>>>> return wrapperStyle;
>>>> }
>>>>
>>>>I.e. I'm letting it pass if there are no input parts at all which I
>>>>believe
>>>>is valid according the the JAX-WS 2.0 spec
>>>>
>>>>2/ Fixed the getWrapperInfo method to take account of the case where
>>
>>there
>>
>>>>are no input params
>>>>
>>>> if (in != null) {
>>>> for (XmlSchemaElement e : getInputChildElements()) {
>>>> inChildren.add(getElementInfo(e));
>>>> }
>>>> }
>>>>
>>>>3/ Fixed the Axis2 binding to properly deal with the case when no
>>>>parameters
>>>>are present in Axis2ServiceInOutSyncMessageReceiver.
>>>>
>>>> public void invokeBusinessLogic(MessageContext inMC, MessageContext
>>>>outMC) throws AxisFault {
>>>> try {
>>>> OMElement requestOM = inMC.getEnvelope
>>>>().getBody().getFirstElement();
>>>> Object[] args = null;
>>>>
>>>> if (requestOM != null) {
>>>> args = new Object[] {requestOM};
>>>> }
>>>>
>>>>The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
>>>>
>>>>This works with the forward message relying on the soap action to
>>>>indentify
>>>>the correct operation.
>>>>
>>>>I haven't checked this in as the code seems to have been carefully
>>
>>crafted
>>
>>>>to assume that there will always be an input parameter. Can someone
>>>>explain
>>>>why this is thought to be the case?
>>>
>>>
>>>
>>>If there's no objections very soon then how about just doing this fix
>>
>>for
>>
>>>now so Tuscany tolerates the Axis2 way for now (and something similar
>>
>>for
>>
>>>TUSCANY-1658)?
>>>
>>> ...ant
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>We seem to be agreeing that patching up the axis generators is no ideal
>
>
> I quite like the sound of fixing up the WSDL after it's generated.
>
> We do WSDL generation in several places so we would have to trap them
> (ideally by rationalizing to use only one set of code if we can)
>
> Regards
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/5/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> I have concerns about making the Tuscany code wrong to compensate for
> the generated WSDL being wrong. This feels like a step in the wrong
> direction, and it won't allow non-Tuscany Web service clients to call
> Tuscany services that use generated WSDL.
>
> Instead, I'd prefer to have Tuscany postprocess the incorrect
> WSDLDefinition returned by the Axis2 generator and fix it up so that
> it's correct. The seems much cleaner and more robust that having
> Tuscany override parts of the Axis2 generator code. If in future
> the Axis2 code returns a correct WSDLDefinition, then the Tuscany
> postprocessor can just pass it through unchanged.
>
> I am willing to take on the task of implementing this.
>
> Simon
>
> ant elder wrote:
>
> > On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >>On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >>>
> >>>
> >>>On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>The operation.getInput() cannot be null to qualify for the wrapper
> >>>>style.
> >>>>There must be a part in the input message corresponding to the
> >>
> >>operation
> >>
> >>>>name:
> >>>>
> >>>>input
> >>>> --- message
> >>>> --- part (only one part)
> >>>> --- element (the element name should be the same as
> >>
> >>the
> >>
> >>>>operation name)
> >>>>
> >>>>The element should look like this:
> >>>>
> >>>><element name="myMethod">
> >>>> <complexType>
> >>>> <sequence/> <!-- an empty sequence -->
> >>>> </complexType>
> >>>></element>
> >>>>
> >>>>Thanks,
> >>>>Raymond
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Simon Laws" <si...@googlemail.com>
> >>>>To: "tuscany-dev" <tu...@ws.apache.org>
> >>>>Sent: Friday, August 31, 2007 10:34 AM
> >>>>Subject: Wrapper style test in WSDL processing?
> >>>>
> >>>>
> >>>>
> >>>>>There is a test to determine whether a WSDL operation follows the
> >>>>>"wrapped"
> >>>>>style in accordance with JAX-WS 2.0 spec. See
> >>>>>WSDLOperationIntrospectorImpl
> >>>>>(
> >>>>>
> >>>>
> >>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> >>
> >>>>>)
> >>>>>
> >>>>>The code is currently
> >>>>>
> >>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
> >>>>> if (wrapperStyle == null) {
> >>>>> wrapperStyle =
> >>>>> wrapper.getInputChildElements() != null && (
> >>>>>operation.getOutput() == null || wrapper
> >>>>> .getOutputChildElements() != null);
> >>>>> }
> >>>>> return wrapperStyle;
> >>>>> }
> >>>>>
> >>>>>Which doesn't seem to cater for the case where there may be no input
> >>>>>parameters. I'm diving into this code now to see if I can work out
> >>>>
> >>>>what it
> >>>>
> >>>>>means but if anyone has any insight I would appreciate it.
> >>>>>
> >>>>>Needless to say I have a scenario where I am trying to auto generate
> >>>>
> >>>>WSDL
> >>>>
> >>>>>for a method with the signature
> >>>>>
> >>>>>String myMethod()
> >>>>>
> >>>>>And it's complaining that it's not wrapped.
> >>>>>
> >>>>>Simon
> >>>>>
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>>What you are saying sounds right to me, I.e. you can validly have no
> >>>
> >>>parameters in your method but in this case it should build an empty
> >>
> >>sequence
> >>
> >>>
> >>><element name="myMethod">
> >>> <complexType>
> >>> <sequence/> <!-- an empty sequence -->
> >>> </complexType>
> >>></element>
> >>>
> >>>And have this as the single input type. I'm deeper into the code now
> >>>looking for why this isn't the case.
> >>>
> >>>Thanks Raymond
> >>>
> >>>Simon
> >>>
> >>
> >>I've done a bit more investigation now. For the signature
> >>
> >>String foo()
> >>
> >>Axis2 Java2WSDL generates
> >>
> >> <wsdl:types>
> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >> attributeFormDefault="qualified"
> >>elementFormDefault="qualified"
> >> targetNamespace="http://test/xsd">
> >> <xs:element name="fooResponse">
> >> <xs:complexType>
> >> <xs:sequence>
> >> <xs:element name="return" nillable="true"
> >> type="xs:string" />
> >> </xs:sequence>
> >> </xs:complexType>
> >> </xs:element>
> >> </xs:schema>
> >> </wsdl:types>
> >> <wsdl:message name="fooMessage" />
> >> <wsdl:message name="fooResponseMessage">
> >> <wsdl:part name="part1" element="ns:fooResponse" />
> >> </wsdl:message>
> >>
> >>So in our code when it comes to testing for wrapped it returns false
> >>because
> >>this doesn't match the algorithm that was presented earlier in this
> >>thread,
> >>i.e. there is no part of the input message corresponding to the message
> >>name. So when you try this in Tuscany is throws an exception saying that
> >>the
> >>operation is not wrapped.
> >>
> >>It would be inconvenient for us to not support operations with no
> >>parameters. As the wsdl generation process assumes that the target
> >>operations will be generated as wrapped operations here's what I did..
> >>
> >>1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
> to
> >>read.
> >>
> >> public boolean isWrapperStyle() throws InvalidWSDLException {
> >> if (wrapperStyle == null) {
> >> wrapperStyle =
> >> (operation.getInput
> >>().getMessage().getParts().values().size()
> >>== 0 ||wrapper.getInputChildElements() != null) &&
> >> (operation.getOutput() == null ||
> >>wrapper.getOutputChildElements() != null);
> >> }
> >> return wrapperStyle;
> >> }
> >>
> >>I.e. I'm letting it pass if there are no input parts at all which I
> >>believe
> >>is valid according the the JAX-WS 2.0 spec
> >>
> >>2/ Fixed the getWrapperInfo method to take account of the case where
> there
> >>are no input params
> >>
> >> if (in != null) {
> >> for (XmlSchemaElement e : getInputChildElements()) {
> >> inChildren.add(getElementInfo(e));
> >> }
> >> }
> >>
> >>3/ Fixed the Axis2 binding to properly deal with the case when no
> >>parameters
> >>are present in Axis2ServiceInOutSyncMessageReceiver.
> >>
> >> public void invokeBusinessLogic(MessageContext inMC, MessageContext
> >>outMC) throws AxisFault {
> >> try {
> >> OMElement requestOM = inMC.getEnvelope
> >>().getBody().getFirstElement();
> >> Object[] args = null;
> >>
> >> if (requestOM != null) {
> >> args = new Object[] {requestOM};
> >> }
> >>
> >>The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
> >>
> >>This works with the forward message relying on the soap action to
> >>indentify
> >>the correct operation.
> >>
> >>I haven't checked this in as the code seems to have been carefully
> crafted
> >>to assume that there will always be an input parameter. Can someone
> >>explain
> >>why this is thought to be the case?
> >
> >
> >
> > If there's no objections very soon then how about just doing this fix
> for
> > now so Tuscany tolerates the Axis2 way for now (and something similar
> for
> > TUSCANY-1658)?
> >
> > ...ant
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> We seem to be agreeing that patching up the axis generators is no ideal
I quite like the sound of fixing up the WSDL after it's generated.
We do WSDL generation in several places so we would have to trap them
(ideally by rationalizing to use only one set of code if we can)
Regards
Simon
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
I have concerns about making the Tuscany code wrong to compensate for
the generated WSDL being wrong. This feels like a step in the wrong
direction, and it won't allow non-Tuscany Web service clients to call
Tuscany services that use generated WSDL.
Instead, I'd prefer to have Tuscany postprocess the incorrect
WSDLDefinition returned by the Axis2 generator and fix it up so that
it's correct. The seems much cleaner and more robust that having
Tuscany override parts of the Axis2 generator code. If in future
the Axis2 code returns a correct WSDLDefinition, then the Tuscany
postprocessor can just pass it through unchanged.
I am willing to take on the task of implementing this.
Simon
ant elder wrote:
> On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
>
>>On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>>
>>>
>>>On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
>>>
>>>>Hi,
>>>>
>>>>The operation.getInput() cannot be null to qualify for the wrapper
>>>>style.
>>>>There must be a part in the input message corresponding to the
>>
>>operation
>>
>>>>name:
>>>>
>>>>input
>>>> --- message
>>>> --- part (only one part)
>>>> --- element (the element name should be the same as
>>
>>the
>>
>>>>operation name)
>>>>
>>>>The element should look like this:
>>>>
>>>><element name="myMethod">
>>>> <complexType>
>>>> <sequence/> <!-- an empty sequence -->
>>>> </complexType>
>>>></element>
>>>>
>>>>Thanks,
>>>>Raymond
>>>>
>>>>----- Original Message -----
>>>>From: "Simon Laws" <si...@googlemail.com>
>>>>To: "tuscany-dev" <tu...@ws.apache.org>
>>>>Sent: Friday, August 31, 2007 10:34 AM
>>>>Subject: Wrapper style test in WSDL processing?
>>>>
>>>>
>>>>
>>>>>There is a test to determine whether a WSDL operation follows the
>>>>>"wrapped"
>>>>>style in accordance with JAX-WS 2.0 spec. See
>>>>>WSDLOperationIntrospectorImpl
>>>>>(
>>>>>
>>>>
>>http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
>>
>>>>>)
>>>>>
>>>>>The code is currently
>>>>>
>>>>> public boolean isWrapperStyle() throws InvalidWSDLException {
>>>>> if (wrapperStyle == null) {
>>>>> wrapperStyle =
>>>>> wrapper.getInputChildElements() != null && (
>>>>>operation.getOutput() == null || wrapper
>>>>> .getOutputChildElements() != null);
>>>>> }
>>>>> return wrapperStyle;
>>>>> }
>>>>>
>>>>>Which doesn't seem to cater for the case where there may be no input
>>>>>parameters. I'm diving into this code now to see if I can work out
>>>>
>>>>what it
>>>>
>>>>>means but if anyone has any insight I would appreciate it.
>>>>>
>>>>>Needless to say I have a scenario where I am trying to auto generate
>>>>
>>>>WSDL
>>>>
>>>>>for a method with the signature
>>>>>
>>>>>String myMethod()
>>>>>
>>>>>And it's complaining that it's not wrapped.
>>>>>
>>>>>Simon
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>What you are saying sounds right to me, I.e. you can validly have no
>>>
>>>parameters in your method but in this case it should build an empty
>>
>>sequence
>>
>>>
>>><element name="myMethod">
>>> <complexType>
>>> <sequence/> <!-- an empty sequence -->
>>> </complexType>
>>></element>
>>>
>>>And have this as the single input type. I'm deeper into the code now
>>>looking for why this isn't the case.
>>>
>>>Thanks Raymond
>>>
>>>Simon
>>>
>>
>>I've done a bit more investigation now. For the signature
>>
>>String foo()
>>
>>Axis2 Java2WSDL generates
>>
>> <wsdl:types>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> attributeFormDefault="qualified"
>>elementFormDefault="qualified"
>> targetNamespace="http://test/xsd">
>> <xs:element name="fooResponse">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="return" nillable="true"
>> type="xs:string" />
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:schema>
>> </wsdl:types>
>> <wsdl:message name="fooMessage" />
>> <wsdl:message name="fooResponseMessage">
>> <wsdl:part name="part1" element="ns:fooResponse" />
>> </wsdl:message>
>>
>>So in our code when it comes to testing for wrapped it returns false
>>because
>>this doesn't match the algorithm that was presented earlier in this
>>thread,
>>i.e. there is no part of the input message corresponding to the message
>>name. So when you try this in Tuscany is throws an exception saying that
>>the
>>operation is not wrapped.
>>
>>It would be inconvenient for us to not support operations with no
>>parameters. As the wsdl generation process assumes that the target
>>operations will be generated as wrapped operations here's what I did..
>>
>>1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl) to
>>read.
>>
>> public boolean isWrapperStyle() throws InvalidWSDLException {
>> if (wrapperStyle == null) {
>> wrapperStyle =
>> (operation.getInput
>>().getMessage().getParts().values().size()
>>== 0 ||wrapper.getInputChildElements() != null) &&
>> (operation.getOutput() == null ||
>>wrapper.getOutputChildElements() != null);
>> }
>> return wrapperStyle;
>> }
>>
>>I.e. I'm letting it pass if there are no input parts at all which I
>>believe
>>is valid according the the JAX-WS 2.0 spec
>>
>>2/ Fixed the getWrapperInfo method to take account of the case where there
>>are no input params
>>
>> if (in != null) {
>> for (XmlSchemaElement e : getInputChildElements()) {
>> inChildren.add(getElementInfo(e));
>> }
>> }
>>
>>3/ Fixed the Axis2 binding to properly deal with the case when no
>>parameters
>>are present in Axis2ServiceInOutSyncMessageReceiver.
>>
>> public void invokeBusinessLogic(MessageContext inMC, MessageContext
>>outMC) throws AxisFault {
>> try {
>> OMElement requestOM = inMC.getEnvelope
>>().getBody().getFirstElement();
>> Object[] args = null;
>>
>> if (requestOM != null) {
>> args = new Object[] {requestOM};
>> }
>>
>>The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
>>
>>This works with the forward message relying on the soap action to
>>indentify
>>the correct operation.
>>
>>I haven't checked this in as the code seems to have been carefully crafted
>>to assume that there will always be an input parameter. Can someone
>>explain
>>why this is thought to be the case?
>
>
>
> If there's no objections very soon then how about just doing this fix for
> now so Tuscany tolerates the Axis2 way for now (and something similar for
> TUSCANY-1658)?
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by ant elder <an...@gmail.com>.
On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >
> >
> > On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > The operation.getInput() cannot be null to qualify for the wrapper
> > > style.
> > > There must be a part in the input message corresponding to the
> operation
> > > name:
> > >
> > > input
> > > --- message
> > > --- part (only one part)
> > > --- element (the element name should be the same as
> the
> > > operation name)
> > >
> > > The element should look like this:
> > >
> > > <element name="myMethod">
> > > <complexType>
> > > <sequence/> <!-- an empty sequence -->
> > > </complexType>
> > > </element>
> > >
> > > Thanks,
> > > Raymond
> > >
> > > ----- Original Message -----
> > > From: "Simon Laws" <si...@googlemail.com>
> > > To: "tuscany-dev" <tu...@ws.apache.org>
> > > Sent: Friday, August 31, 2007 10:34 AM
> > > Subject: Wrapper style test in WSDL processing?
> > >
> > >
> > > > There is a test to determine whether a WSDL operation follows the
> > > > "wrapped"
> > > > style in accordance with JAX-WS 2.0 spec. See
> > > > WSDLOperationIntrospectorImpl
> > > > (
> > > >
> > >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> > > > )
> > > >
> > > > The code is currently
> > > >
> > > > public boolean isWrapperStyle() throws InvalidWSDLException {
> > > > if (wrapperStyle == null) {
> > > > wrapperStyle =
> > > > wrapper.getInputChildElements() != null && (
> > > > operation.getOutput() == null || wrapper
> > > > .getOutputChildElements() != null);
> > > > }
> > > > return wrapperStyle;
> > > > }
> > > >
> > > > Which doesn't seem to cater for the case where there may be no input
> > > > parameters. I'm diving into this code now to see if I can work out
> > > what it
> > > > means but if anyone has any insight I would appreciate it.
> > > >
> > > > Needless to say I have a scenario where I am trying to auto generate
> > > WSDL
> > > > for a method with the signature
> > > >
> > > > String myMethod()
> > > >
> > > > And it's complaining that it's not wrapped.
> > > >
> > > > Simon
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > What you are saying sounds right to me, I.e. you can validly have no
> > parameters in your method but in this case it should build an empty
> sequence
> >
> >
> > <element name="myMethod">
> > <complexType>
> > <sequence/> <!-- an empty sequence -->
> > </complexType>
> > </element>
> >
> > And have this as the single input type. I'm deeper into the code now
> > looking for why this isn't the case.
> >
> > Thanks Raymond
> >
> > Simon
> >
> I've done a bit more investigation now. For the signature
>
> String foo()
>
> Axis2 Java2WSDL generates
>
> <wsdl:types>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> attributeFormDefault="qualified"
> elementFormDefault="qualified"
> targetNamespace="http://test/xsd">
> <xs:element name="fooResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="return" nillable="true"
> type="xs:string" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:schema>
> </wsdl:types>
> <wsdl:message name="fooMessage" />
> <wsdl:message name="fooResponseMessage">
> <wsdl:part name="part1" element="ns:fooResponse" />
> </wsdl:message>
>
> So in our code when it comes to testing for wrapped it returns false
> because
> this doesn't match the algorithm that was presented earlier in this
> thread,
> i.e. there is no part of the input message corresponding to the message
> name. So when you try this in Tuscany is throws an exception saying that
> the
> operation is not wrapped.
>
> It would be inconvenient for us to not support operations with no
> parameters. As the wsdl generation process assumes that the target
> operations will be generated as wrapped operations here's what I did..
>
> 1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl) to
> read.
>
> public boolean isWrapperStyle() throws InvalidWSDLException {
> if (wrapperStyle == null) {
> wrapperStyle =
> (operation.getInput
> ().getMessage().getParts().values().size()
> == 0 ||wrapper.getInputChildElements() != null) &&
> (operation.getOutput() == null ||
> wrapper.getOutputChildElements() != null);
> }
> return wrapperStyle;
> }
>
> I.e. I'm letting it pass if there are no input parts at all which I
> believe
> is valid according the the JAX-WS 2.0 spec
>
> 2/ Fixed the getWrapperInfo method to take account of the case where there
> are no input params
>
> if (in != null) {
> for (XmlSchemaElement e : getInputChildElements()) {
> inChildren.add(getElementInfo(e));
> }
> }
>
> 3/ Fixed the Axis2 binding to properly deal with the case when no
> parameters
> are present in Axis2ServiceInOutSyncMessageReceiver.
>
> public void invokeBusinessLogic(MessageContext inMC, MessageContext
> outMC) throws AxisFault {
> try {
> OMElement requestOM = inMC.getEnvelope
> ().getBody().getFirstElement();
> Object[] args = null;
>
> if (requestOM != null) {
> args = new Object[] {requestOM};
> }
>
> The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
>
> This works with the forward message relying on the soap action to
> indentify
> the correct operation.
>
> I haven't checked this in as the code seems to have been carefully crafted
> to assume that there will always be an input parameter. Can someone
> explain
> why this is thought to be the case?
If there's no objections very soon then how about just doing this fix for
now so Tuscany tolerates the Axis2 way for now (and something similar for
TUSCANY-1658)?
...ant
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Laws wrote:
> On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
>
>>Note that we have a similar issue that I'm looking at under the
>>wsdl2java tooling, described in this post [1]
>>
>>[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
>>
>>On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>>>Jean-Sebastien Delfino wrote:
>>>
>>>>[snip]
>>>>Simon Laws wrote:
>>>>
>>>>>I've done a bit more investigation now. For the signature
>>>>>
>>>>>String foo()
>>>>>
>>>>>Axis2 Java2WSDL generates
>>>>>
>>>>> <wsdl:types>
>>>>> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
>>>>> attributeFormDefault="qualified"
>>>>>elementFormDefault="qualified"
>>>>> targetNamespace=" http://test/xsd">
>>>>> <xs:element name="fooResponse">
>>>>> <xs:complexType>
>>>>> <xs:sequence>
>>>>> <xs:element name="return" nillable="true"
>>>>> type="xs:string" />
>>>>> </xs:sequence>
>>>>> </xs:complexType>
>>>>> </xs:element>
>>>>> </xs:schema>
>>>>> </wsdl:types>
>>>>> <wsdl:message name="fooMessage" />
>>>>> <wsdl:message name="fooResponseMessage">
>>>>> <wsdl:part name="part1" element="ns:fooResponse" />
>>>>> </wsdl:message>
>>>>>
>>>>>
>>>>I'm trying to understand the overall picture before choosing a side:
>>>>- tolerate what Axis2 generates in our isWrapped() algorithm?
>>>>- or fix the WSDL after it's generated by Axis2?
>>>>
>>>>I have the following two questions:
>>>>1) Is it true that the above WSDL has no chance to work at all as it
>>>>doesn't allow the "foo" operation to be sent at all (since there is no
>>
>>>>"foo" element to carry it)?
>>>>
>>>>2) Could you please paste the entire WSDL? including the generated
>>>>binding and service+port? I believe that it'll help answer question
>>
>>(1).
>>
>>>>Thanks
>>>>
>>>
>>>OK, looks like the answer to your question was already in your post, I
>>>should have read it better. In this case, it works with SOAP action.
>>>
>>>I think it's better to tolerate that (incorrect) behavior from Axis2 for
>>>now, as:
>>>(a) I don't think we'll be able to patch all WSDLs that may be generated
>>>by users with the Axis2 tools out of our control
>>>(b) this is a workaround anyway, and a "tolerating" workaround is not
>>>worse than a "patching" workaround, actually it is probably better as it
>>>won't introduce any other side effects
>>>
>>>I also think that we need to open an Axis2 JIRA to report and track this
>>>bug.
>>>
>>>--
>>>Jean-Sebastien
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>>
>>--
>>Luciano Resende
>>Apache Tuscany Committer
>>http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>>http://lresende.blogspot.com/
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>So several points coming out here. Let me try and catch them (in no
>
> particular order)
>
> Issue1 - we have more than one piece of code in Tuscany that generates WSDL
> (using underlying Axis2 tools but possibly in different ways)
> Solution
> Do WSDL generation in one place.
>
> Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of
> wrapped which we have set out to support
> Solution1
> get Axis to fix it
> Solution2 (stop gap)
> post process the generated WSDL to correct it for Tuscany
>
> Issue3 - Service providers and consumer outside of Tuscany may generate
> broken WSDL and reasonably expect their messages to work with Tuscany
> Solution
> There is a fix available to make inbound Axis2 processing lax to the
> extent that it handlse Axis2 version of a null parameter operation
> A fix is required for void return values
>
> It sounds like
>
> We could address Issue1 if it's possible
> - need Luciano/Ant to say if this is possible and/or worth it
>
> We should address Issue2 Solution 1
> - well get it moving at least
>
> We could address Issue2 Solution2
> - I quite like the idea of producing the correct WSDL as we see it but
> there is concern that we don't know if it we will break someone who relies
> on the WSDL the way axis produces it. This makes the assumption that it
> works for more people in its current form that it does in it's fixed up
> form. Which in turn is based on people being happy using Axis2. Warrants a
> bit of investigation.
>
This sounds a bit like "maybe we should do this wrong because there is
one (at least) buggy implementation out there that could be broken if
we do it right".
I was really hoping that we would be able to avoid debating this point
if Axis2 could handle the "right" form of WSDL. But my first experiment
in calling a no-argument method using hand-edited explicit WSDL with the
recommended wrapper style and soap:action has not succeeded. I'm too
tired now to figure out whether it's me or Axis2 doing something wrong,
so I'll resume my investigations in the morning.
Simon
> We should address Issue3
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by Luciano Resende <lu...@gmail.com>.
In the case I'm investigating, the issue is around checking if the
wrapper style is in use for the wsdl, but the problem is that
wsdl2java generates wrong interfaces for the wsdl in question.
On 9/5/07, Simon Laws <si...@googlemail.com> wrote:
> On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Note that we have a similar issue that I'm looking at under the
> > wsdl2java tooling, described in this post [1]
> >
> > [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
> >
> > On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > Jean-Sebastien Delfino wrote:
> > > > [snip]
> > > > Simon Laws wrote:
> > > >> I've done a bit more investigation now. For the signature
> > > >>
> > > >> String foo()
> > > >>
> > > >> Axis2 Java2WSDL generates
> > > >>
> > > >> <wsdl:types>
> > > >> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
> > > >> attributeFormDefault="qualified"
> > > >> elementFormDefault="qualified"
> > > >> targetNamespace=" http://test/xsd">
> > > >> <xs:element name="fooResponse">
> > > >> <xs:complexType>
> > > >> <xs:sequence>
> > > >> <xs:element name="return" nillable="true"
> > > >> type="xs:string" />
> > > >> </xs:sequence>
> > > >> </xs:complexType>
> > > >> </xs:element>
> > > >> </xs:schema>
> > > >> </wsdl:types>
> > > >> <wsdl:message name="fooMessage" />
> > > >> <wsdl:message name="fooResponseMessage">
> > > >> <wsdl:part name="part1" element="ns:fooResponse" />
> > > >> </wsdl:message>
> > > >>
> > > >>
> > > >
> > > > I'm trying to understand the overall picture before choosing a side:
> > > > - tolerate what Axis2 generates in our isWrapped() algorithm?
> > > > - or fix the WSDL after it's generated by Axis2?
> > > >
> > > > I have the following two questions:
> > > > 1) Is it true that the above WSDL has no chance to work at all as it
> > > > doesn't allow the "foo" operation to be sent at all (since there is no
> >
> > > > "foo" element to carry it)?
> > > >
> > > > 2) Could you please paste the entire WSDL? including the generated
> > > > binding and service+port? I believe that it'll help answer question
> > (1).
> > > >
> > > > Thanks
> > > >
> > >
> > > OK, looks like the answer to your question was already in your post, I
> > > should have read it better. In this case, it works with SOAP action.
> > >
> > > I think it's better to tolerate that (incorrect) behavior from Axis2 for
> > > now, as:
> > > (a) I don't think we'll be able to patch all WSDLs that may be generated
> > > by users with the Axis2 tools out of our control
> > > (b) this is a workaround anyway, and a "tolerating" workaround is not
> > > worse than a "patching" workaround, actually it is probably better as it
> > > won't introduce any other side effects
> > >
> > > I also think that we need to open an Axis2 JIRA to report and track this
> > > bug.
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > So several points coming out here. Let me try and catch them (in no
> particular order)
>
> Issue1 - we have more than one piece of code in Tuscany that generates WSDL
> (using underlying Axis2 tools but possibly in different ways)
> Solution
> Do WSDL generation in one place.
>
> Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of
> wrapped which we have set out to support
> Solution1
> get Axis to fix it
> Solution2 (stop gap)
> post process the generated WSDL to correct it for Tuscany
>
> Issue3 - Service providers and consumer outside of Tuscany may generate
> broken WSDL and reasonably expect their messages to work with Tuscany
> Solution
> There is a fix available to make inbound Axis2 processing lax to the
> extent that it handlse Axis2 version of a null parameter operation
> A fix is required for void return values
>
> It sounds like
>
> We could address Issue1 if it's possible
> - need Luciano/Ant to say if this is possible and/or worth it
>
> We should address Issue2 Solution 1
> - well get it moving at least
>
> We could address Issue2 Solution2
> - I quite like the idea of producing the correct WSDL as we see it but
> there is concern that we don't know if it we will break someone who relies
> on the WSDL the way axis produces it. This makes the assumption that it
> works for more people in its current form that it does in it's fixed up
> form. Which in turn is based on people being happy using Axis2. Warrants a
> bit of investigation.
>
> We should address Issue3
>
> Simon
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by ant elder <an...@gmail.com>.
On 9/9/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
>
> Simon Nash wrote:
>
> > (cut)
> >>
> >>> We can't get that done by our 1.0 though so need something for now.
> >>> We're
> >>> not planing on attempting to pass the jaxws tck so i'd be happy if we
> >>> just
> >>> have something that works even if we suspect it may not be fully jaxws
> >>> compliant as long as Tuscany services and references can talk to each
> >>> other
> >>> or to native axis2 clients and services. So i still quite like the
> >>> fix that
> >>> Simon L proposed early on in this thread.
> >>>
> >>> ...ant
> >>>
> >> I have now got my test case working to show Tuscany services and
> >> references talking to each other using an augmented version of the
> >> WSDL generated by Axis2 Java2WSDL (hand edited currently) with an
> >> empty wrapper for the no parameters case. There's a small fix
> >> needed in the databinding framework to deal with void return types
> >> when there are no parameters. I have a patch and I'll post it soon.
> >>
> >> The next step is to see whether this works for Tuscany services and
> >> references talking to native Axis2 clients and services. I'll look
> >> into this later and post my findings tomorrow.
> >>
> > I spent a while playing with this without making a lot of progress.
> > The ADB stubs gererated by Axis2's WSDL2Java are not the easiest to
> > decipher! Then I came across a very useful example/tutorial in the
> > Axis2 documentation (see [1]) that shows "wrapped no parameter" style
> > WSDL being used with Axis2's WSDL2Java to generate clients for ADB,
> > XMLBeans, and JiBX. This was very encouraging as it provides some
> > confirmation that "wrapped no parameter" style WSDL is valid for Axis2.
> >
> > I'm now working through the steps in this tutorial to take this form
> > of "wrapped no parameter" WSDL and create an Axis2 client that talks
> > to a Tuscany service that uses the same WSDL. If successful, this
> > will confirm that having an empty wrapper element in generated WSDL
> > on the Tuscany service side doesn't cause any problems when an Axis2
> > client is talking to these Tuscany services.
> >
> I can now confirm that calls from a pure Axis2 client to a Tuscany
> service do work with "wrapped no parameter" WSDL. Given that there
> isn't an interoperability issue, I think we should postprocess the
> Axis2-generated WSDL to add these "no parameter" wrappers when needed.
>
> Does anyone disagree with this? If not, I will work on a patch.
I still think you should talk to the Axis2 guys before patching the wsdl as
it may be just something we're doing wrong with setting up Axis2. Or if
there is a bug maybe its fixed in Axis2 1.3 or there's a Axis2 fix we could
port to the code we use.
...ant
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Nash wrote:
> (cut)
>>
>>> We can't get that done by our 1.0 though so need something for now.
>>> We're
>>> not planing on attempting to pass the jaxws tck so i'd be happy if we
>>> just
>>> have something that works even if we suspect it may not be fully jaxws
>>> compliant as long as Tuscany services and references can talk to each
>>> other
>>> or to native axis2 clients and services. So i still quite like the
>>> fix that
>>> Simon L proposed early on in this thread.
>>>
>>> ...ant
>>>
>> I have now got my test case working to show Tuscany services and
>> references talking to each other using an augmented version of the
>> WSDL generated by Axis2 Java2WSDL (hand edited currently) with an
>> empty wrapper for the no parameters case. There's a small fix
>> needed in the databinding framework to deal with void return types
>> when there are no parameters. I have a patch and I'll post it soon.
>>
>> The next step is to see whether this works for Tuscany services and
>> references talking to native Axis2 clients and services. I'll look
>> into this later and post my findings tomorrow.
>>
> I spent a while playing with this without making a lot of progress.
> The ADB stubs gererated by Axis2's WSDL2Java are not the easiest to
> decipher! Then I came across a very useful example/tutorial in the
> Axis2 documentation (see [1]) that shows "wrapped no parameter" style
> WSDL being used with Axis2's WSDL2Java to generate clients for ADB,
> XMLBeans, and JiBX. This was very encouraging as it provides some
> confirmation that "wrapped no parameter" style WSDL is valid for Axis2.
>
> I'm now working through the steps in this tutorial to take this form
> of "wrapped no parameter" WSDL and create an Axis2 client that talks
> to a Tuscany service that uses the same WSDL. If successful, this
> will confirm that having an empty wrapper element in generated WSDL
> on the Tuscany service side doesn't cause any problems when an Axis2
> client is talking to these Tuscany services.
>
I can now confirm that calls from a pure Axis2 client to a Tuscany
service do work with "wrapped no parameter" WSDL. Given that there
isn't an interoperability issue, I think we should postprocess the
Axis2-generated WSDL to add these "no parameter" wrappers when needed.
Does anyone disagree with this? If not, I will work on a patch.
Simon
> For the opposite case of Tuscany clients talking to Axis2 services,
> we need to make sure that Tuscany can support the "empty body"
> style of wrapped WSDL that's generated by Axis2's Java2WSDL. For
> this support, we'll need the fix that SimonL has produced.
>
> I also looked at the code generated by Java2WSDL in CXF and wsgen
> in JDK 6. (wsgen is JDK 6's Java to WSDL generator). Both of these
> generate the empty wrapper element for the no parameters case, so it
> does rather look like it's Axis2 that's out of step here.
>
> Simon
>
> [1]
> http://ws.apache.org/axis2/1_3/userguide-creatingclients.html#createclients
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Simon Nash wrote:
> See inline.
>
> Simon
>
> ant elder wrote:
>
>> On 9/5/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>> On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
>>>
>>>> Note that we have a similar issue that I'm looking at under the
>>>> wsdl2java tooling, described in this post [1]
>>>>
>>>> [1]
>>>
>>>
>>> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
>>>
>>>> On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>>
>>>>> Jean-Sebastien Delfino wrote:
>>>>>
>>>>>> [snip]
>>>>>> Simon Laws wrote:
>>>>>>
>>>>>>> I've done a bit more investigation now. For the signature
>>>>>>>
>>>>>>> String foo()
>>>>>>>
>>>>>>> Axis2 Java2WSDL generates
>>>>>>>
>>>>>>> <wsdl:types>
>>>>>>> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
>>>>>>> attributeFormDefault="qualified"
>>>>>>> elementFormDefault="qualified"
>>>>>>> targetNamespace=" http://test/xsd">
>>>>>>> <xs:element name="fooResponse">
>>>>>>> <xs:complexType>
>>>>>>> <xs:sequence>
>>>>>>> <xs:element name="return" nillable="true"
>>>>>>> type="xs:string" />
>>>>>>> </xs:sequence>
>>>>>>> </xs:complexType>
>>>>>>> </xs:element>
>>>>>>> </xs:schema>
>>>>>>> </wsdl:types>
>>>>>>> <wsdl:message name="fooMessage" />
>>>>>>> <wsdl:message name="fooResponseMessage">
>>>>>>> <wsdl:part name="part1" element="ns:fooResponse" />
>>>>>>> </wsdl:message>
>>>>>>>
>>>>>>>
>>>>>> I'm trying to understand the overall picture before choosing a side:
>>>>>> - tolerate what Axis2 generates in our isWrapped() algorithm?
>>>>>> - or fix the WSDL after it's generated by Axis2?
>>>>>>
>>>>>> I have the following two questions:
>>>>>> 1) Is it true that the above WSDL has no chance to work at all as it
>>>>>> doesn't allow the "foo" operation to be sent at all (since there is
>>>
>>>
>>> no
>>>
>>>>>> "foo" element to carry it)?
>>>>>>
>>>>>> 2) Could you please paste the entire WSDL? including the generated
>>>>>> binding and service+port? I believe that it'll help answer question
>>>>
>>>>
>>>> (1).
>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>> OK, looks like the answer to your question was already in your post, I
>>>>> should have read it better. In this case, it works with SOAP action.
>>>>>
>>>>> I think it's better to tolerate that (incorrect) behavior from Axis2
>>>
>>>
>>> for
>>>
>>>>> now, as:
>>>>> (a) I don't think we'll be able to patch all WSDLs that may be
>>>
>>>
>>> generated
>>>
>>>>> by users with the Axis2 tools out of our control
>>>>> (b) this is a workaround anyway, and a "tolerating" workaround is not
>>>>> worse than a "patching" workaround, actually it is probably better as
>>>
>>>
>>> it
>>>
>>>>> won't introduce any other side effects
>>>>>
>>>>> I also think that we need to open an Axis2 JIRA to report and track
>>>
>>>
>>> this
>>>
>>>>> bug.
>>>>>
>>>>> --
>>>>> Jean-Sebastien
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Luciano Resende
>>>> Apache Tuscany Committer
>>>> http://people.apache.org/~lresende
>>>> <http://people.apache.org/%7Elresende
>>>>
>>>> http://lresende.blogspot.com/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>> So several points coming out here. Let me try and catch them (in no
>>>
>>>
>>> particular order)
>>>
>>> Issue1 - we have more than one piece of code in Tuscany that generates
>>> WSDL
>>> (using underlying Axis2 tools but possibly in different ways)
>>> Solution
>>> Do WSDL generation in one place.
>>>
>>> Issue2 - The WSDL that is generated doesn't match the JAX-WS
>>> definition of
>>> wrapped which we have set out to support
>>> Solution1
>>> get Axis to fix it
>>> Solution2 (stop gap)
>>> post process the generated WSDL to correct it for Tuscany
>>>
>>> Issue3 - Service providers and consumer outside of Tuscany may generate
>>> broken WSDL and reasonably expect their messages to work with Tuscany
>>> Solution
>>> There is a fix available to make inbound Axis2 processing lax to the
>>> extent that it handlse Axis2 version of a null parameter operation
>>> A fix is required for void return values
>>>
>>> It sounds like
>>>
>>> We could address Issue1 if it's possible
>>> - need Luciano/Ant to say if this is possible and/or worth it
>>>
>>> We should address Issue2 Solution 1
>>> - well get it moving at least
>>>
>>> We could address Issue2 Solution2
>>> - I quite like the idea of producing the correct WSDL as we see it
>>> but
>>> there is concern that we don't know if it we will break someone who
>>> relies
>>> on the WSDL the way axis produces it. This makes the assumption that it
>>> works for more people in its current form that it does in it's fixed up
>>> form. Which in turn is based on people being happy using Axis2.
>>> Warrants a
>>> bit of investigation.
>>>
>>> We should address Issue3
>>
>>
>>
>>
>> I agree this should be brought up with the Axis2 guys before we go
>> ahead and
>> try to patch the wsdl. Maybe there is some reason its this way, maybe
>> there
>> is some option we're not using to get the wsdl the way we want. Axis2 has
>> passed the JAXWS TCK and its had lots of interop testing and fixing done
>> with lots of other systems, and they are the WS experts not us.
>>
> WS-I has a fair bit of experience with interop as well, and the SCA
> spec for the Web Service binding says that only WS-I compliant mapping is
> supported. The input I have received from one of the WS-I Basic Profile
> authors (see my post from yesterday) is that an approach that uses
> soap:action to disambiguate between different operations without
> parameters is not WS-I compliant.
>
> I agree that we have to be able to support native Axis2 interop (see my
> comments below), but that's not the whole picture.
>
>> I think the ultimate goal should be for SDO to be a proper Axis2
>> supported
>> data binding just as other data bindings like adb, jibx and jaxb are.
>> That
>> way we can just remove the tools from Tuscany and have all the code in
>> axis2. That will make our lives much easier not having to keep copying
>> and
>> patching the axis2 code, and it will help encourage the use of SDO.
>>
> I have not suggested copying and patching the Axis2 code. There are
> serious maintenance issues with this, as you point out. A postprocessing
> approach (where this is practical) should be much more reliable.
>
>> We can't get that done by our 1.0 though so need something for now. We're
>> not planing on attempting to pass the jaxws tck so i'd be happy if we
>> just
>> have something that works even if we suspect it may not be fully jaxws
>> compliant as long as Tuscany services and references can talk to each
>> other
>> or to native axis2 clients and services. So i still quite like the fix
>> that
>> Simon L proposed early on in this thread.
>>
>> ...ant
>>
> I have now got my test case working to show Tuscany services and
> references talking to each other using an augmented version of the
> WSDL generated by Axis2 Java2WSDL (hand edited currently) with an
> empty wrapper for the no parameters case. There's a small fix
> needed in the databinding framework to deal with void return types
> when there are no parameters. I have a patch and I'll post it soon.
>
> The next step is to see whether this works for Tuscany services and
> references talking to native Axis2 clients and services. I'll look
> into this later and post my findings tomorrow.
>
I spent a while playing with this without making a lot of progress.
The ADB stubs gererated by Axis2's WSDL2Java are not the easiest to
decipher! Then I came across a very useful example/tutorial in the
Axis2 documentation (see [1]) that shows "wrapped no parameter" style
WSDL being used with Axis2's WSDL2Java to generate clients for ADB,
XMLBeans, and JiBX. This was very encouraging as it provides some
confirmation that "wrapped no parameter" style WSDL is valid for Axis2.
I'm now working through the steps in this tutorial to take this form
of "wrapped no parameter" WSDL and create an Axis2 client that talks
to a Tuscany service that uses the same WSDL. If successful, this
will confirm that having an empty wrapper element in generated WSDL
on the Tuscany service side doesn't cause any problems when an Axis2
client is talking to these Tuscany services.
For the opposite case of Tuscany clients talking to Axis2 services,
we need to make sure that Tuscany can support the "empty body"
style of wrapped WSDL that's generated by Axis2's Java2WSDL. For
this support, we'll need the fix that SimonL has produced.
I also looked at the code generated by Java2WSDL in CXF and wsgen
in JDK 6. (wsgen is JDK 6's Java to WSDL generator). Both of these
generate the empty wrapper element for the no parameters case, so it
does rather look like it's Axis2 that's out of step here.
Simon
[1] http://ws.apache.org/axis2/1_3/userguide-creatingclients.html#createclients
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/6/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> See inline.
>
> Simon
>
> ant elder wrote:
>
> > On 9/5/07, Simon Laws <si...@googlemail.com> wrote:
> >
> >>On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
> >>
> >>>Note that we have a similar issue that I'm looking at under the
> >>>wsdl2java tooling, described in this post [1]
> >>>
> >>>[1]
> >>
> >>http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
> >>
> >>>On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>>
> >>>>Jean-Sebastien Delfino wrote:
> >>>>
> >>>>>[snip]
> >>>>>Simon Laws wrote:
> >>>>>
> >>>>>>I've done a bit more investigation now. For the signature
> >>>>>>
> >>>>>>String foo()
> >>>>>>
> >>>>>>Axis2 Java2WSDL generates
> >>>>>>
> >>>>>> <wsdl:types>
> >>>>>> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
> >>>>>> attributeFormDefault="qualified"
> >>>>>>elementFormDefault="qualified"
> >>>>>> targetNamespace=" http://test/xsd">
> >>>>>> <xs:element name="fooResponse">
> >>>>>> <xs:complexType>
> >>>>>> <xs:sequence>
> >>>>>> <xs:element name="return" nillable="true"
> >>>>>> type="xs:string" />
> >>>>>> </xs:sequence>
> >>>>>> </xs:complexType>
> >>>>>> </xs:element>
> >>>>>> </xs:schema>
> >>>>>> </wsdl:types>
> >>>>>> <wsdl:message name="fooMessage" />
> >>>>>> <wsdl:message name="fooResponseMessage">
> >>>>>> <wsdl:part name="part1" element="ns:fooResponse" />
> >>>>>> </wsdl:message>
> >>>>>>
> >>>>>>
> >>>>>I'm trying to understand the overall picture before choosing a side:
> >>>>>- tolerate what Axis2 generates in our isWrapped() algorithm?
> >>>>>- or fix the WSDL after it's generated by Axis2?
> >>>>>
> >>>>>I have the following two questions:
> >>>>>1) Is it true that the above WSDL has no chance to work at all as it
> >>>>>doesn't allow the "foo" operation to be sent at all (since there is
> >>
> >>no
> >>
> >>>>>"foo" element to carry it)?
> >>>>>
> >>>>>2) Could you please paste the entire WSDL? including the generated
> >>>>>binding and service+port? I believe that it'll help answer question
> >>>
> >>>(1).
> >>>
> >>>>>Thanks
> >>>>>
> >>>>
> >>>>OK, looks like the answer to your question was already in your post, I
> >>>>should have read it better. In this case, it works with SOAP action.
> >>>>
> >>>>I think it's better to tolerate that (incorrect) behavior from Axis2
> >>
> >>for
> >>
> >>>>now, as:
> >>>>(a) I don't think we'll be able to patch all WSDLs that may be
> >>
> >>generated
> >>
> >>>>by users with the Axis2 tools out of our control
> >>>>(b) this is a workaround anyway, and a "tolerating" workaround is not
> >>>>worse than a "patching" workaround, actually it is probably better as
> >>
> >>it
> >>
> >>>>won't introduce any other side effects
> >>>>
> >>>>I also think that we need to open an Axis2 JIRA to report and track
> >>
> >>this
> >>
> >>>>bug.
> >>>>
> >>>>--
> >>>>Jean-Sebastien
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>--
> >>>Luciano Resende
> >>>Apache Tuscany Committer
> >>>http://people.apache.org/~lresende <
> http://people.apache.org/%7Elresende
> >>>
> >>>http://lresende.blogspot.com/
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>So several points coming out here. Let me try and catch them (in no
> >>
> >>particular order)
> >>
> >>Issue1 - we have more than one piece of code in Tuscany that generates
> >>WSDL
> >>(using underlying Axis2 tools but possibly in different ways)
> >>Solution
> >> Do WSDL generation in one place.
> >>
> >>Issue2 - The WSDL that is generated doesn't match the JAX-WS definition
> of
> >>wrapped which we have set out to support
> >>Solution1
> >> get Axis to fix it
> >>Solution2 (stop gap)
> >> post process the generated WSDL to correct it for Tuscany
> >>
> >>Issue3 - Service providers and consumer outside of Tuscany may generate
> >>broken WSDL and reasonably expect their messages to work with Tuscany
> >>Solution
> >> There is a fix available to make inbound Axis2 processing lax to the
> >>extent that it handlse Axis2 version of a null parameter operation
> >> A fix is required for void return values
> >>
> >>It sounds like
> >>
> >>We could address Issue1 if it's possible
> >> - need Luciano/Ant to say if this is possible and/or worth it
> >>
> >>We should address Issue2 Solution 1
> >> - well get it moving at least
> >>
> >>We could address Issue2 Solution2
> >> - I quite like the idea of producing the correct WSDL as we see it
> but
> >>there is concern that we don't know if it we will break someone who
> relies
> >>on the WSDL the way axis produces it. This makes the assumption that it
> >>works for more people in its current form that it does in it's fixed up
> >>form. Which in turn is based on people being happy using Axis2. Warrants
> a
> >>bit of investigation.
> >>
> >>We should address Issue3
> >
> >
> >
> > I agree this should be brought up with the Axis2 guys before we go ahead
> and
> > try to patch the wsdl. Maybe there is some reason its this way, maybe
> there
> > is some option we're not using to get the wsdl the way we want. Axis2
> has
> > passed the JAXWS TCK and its had lots of interop testing and fixing done
> > with lots of other systems, and they are the WS experts not us.
> >
> WS-I has a fair bit of experience with interop as well, and the SCA
> spec for the Web Service binding says that only WS-I compliant mapping is
> supported. The input I have received from one of the WS-I Basic Profile
> authors (see my post from yesterday) is that an approach that uses
> soap:action to disambiguate between different operations without
> parameters is not WS-I compliant.
>
> I agree that we have to be able to support native Axis2 interop (see my
> comments below), but that's not the whole picture.
>
> > I think the ultimate goal should be for SDO to be a proper Axis2
> supported
> > data binding just as other data bindings like adb, jibx and jaxb are.
> That
> > way we can just remove the tools from Tuscany and have all the code in
> > axis2. That will make our lives much easier not having to keep copying
> and
> > patching the axis2 code, and it will help encourage the use of SDO.
> >
> I have not suggested copying and patching the Axis2 code. There are
> serious maintenance issues with this, as you point out. A postprocessing
> approach (where this is practical) should be much more reliable.
>
> > We can't get that done by our 1.0 though so need something for now.
> We're
> > not planing on attempting to pass the jaxws tck so i'd be happy if we
> just
> > have something that works even if we suspect it may not be fully jaxws
> > compliant as long as Tuscany services and references can talk to each
> other
> > or to native axis2 clients and services. So i still quite like the fix
> that
> > Simon L proposed early on in this thread.
> >
> > ...ant
> >
> I have now got my test case working to show Tuscany services and
> references talking to each other using an augmented version of the
> WSDL generated by Axis2 Java2WSDL (hand edited currently) with an
> empty wrapper for the no parameters case. There's a small fix
> needed in the databinding framework to deal with void return types
> when there are no parameters. I have a patch and I'll post it soon.
>
> The next step is to see whether this works for Tuscany services and
> references talking to native Axis2 clients and services. I'll look
> into this later and post my findings tomorrow.
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> On the basis that we may still encounter WSDL generated outside of Tuscany
I have now checked the change I suggested earlier in this thread in under
revision 573696 and recorded against TUSCANY-1653.
This targets specifically the case of axis2 generated wsdl for operations
with no parameters. It does not address void return types. As before there
are 3 changes. Two of these protect against null pointers and so should be
of no consequence. The change of significance is a one line change to our
isWrapped() test. This now reports true in cases which fall outside the
JAXWS defintion of wrapped.
Assuming it hasn't already been done I'll take the action to ask the
question of the axis team what the status of their WSDL generation is
w.r.tto wrapping no parameter operations.
Regards
Simon
Re: Wrapper style test in WSDL processing?
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
ant elder wrote:
> On 9/5/07, Simon Laws <si...@googlemail.com> wrote:
>
>>On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
>>
>>>Note that we have a similar issue that I'm looking at under the
>>>wsdl2java tooling, described in this post [1]
>>>
>>>[1]
>>
>>http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
>>
>>>On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>>>Jean-Sebastien Delfino wrote:
>>>>
>>>>>[snip]
>>>>>Simon Laws wrote:
>>>>>
>>>>>>I've done a bit more investigation now. For the signature
>>>>>>
>>>>>>String foo()
>>>>>>
>>>>>>Axis2 Java2WSDL generates
>>>>>>
>>>>>> <wsdl:types>
>>>>>> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
>>>>>> attributeFormDefault="qualified"
>>>>>>elementFormDefault="qualified"
>>>>>> targetNamespace=" http://test/xsd">
>>>>>> <xs:element name="fooResponse">
>>>>>> <xs:complexType>
>>>>>> <xs:sequence>
>>>>>> <xs:element name="return" nillable="true"
>>>>>> type="xs:string" />
>>>>>> </xs:sequence>
>>>>>> </xs:complexType>
>>>>>> </xs:element>
>>>>>> </xs:schema>
>>>>>> </wsdl:types>
>>>>>> <wsdl:message name="fooMessage" />
>>>>>> <wsdl:message name="fooResponseMessage">
>>>>>> <wsdl:part name="part1" element="ns:fooResponse" />
>>>>>> </wsdl:message>
>>>>>>
>>>>>>
>>>>>I'm trying to understand the overall picture before choosing a side:
>>>>>- tolerate what Axis2 generates in our isWrapped() algorithm?
>>>>>- or fix the WSDL after it's generated by Axis2?
>>>>>
>>>>>I have the following two questions:
>>>>>1) Is it true that the above WSDL has no chance to work at all as it
>>>>>doesn't allow the "foo" operation to be sent at all (since there is
>>
>>no
>>
>>>>>"foo" element to carry it)?
>>>>>
>>>>>2) Could you please paste the entire WSDL? including the generated
>>>>>binding and service+port? I believe that it'll help answer question
>>>
>>>(1).
>>>
>>>>>Thanks
>>>>>
>>>>
>>>>OK, looks like the answer to your question was already in your post, I
>>>>should have read it better. In this case, it works with SOAP action.
>>>>
>>>>I think it's better to tolerate that (incorrect) behavior from Axis2
>>
>>for
>>
>>>>now, as:
>>>>(a) I don't think we'll be able to patch all WSDLs that may be
>>
>>generated
>>
>>>>by users with the Axis2 tools out of our control
>>>>(b) this is a workaround anyway, and a "tolerating" workaround is not
>>>>worse than a "patching" workaround, actually it is probably better as
>>
>>it
>>
>>>>won't introduce any other side effects
>>>>
>>>>I also think that we need to open an Axis2 JIRA to report and track
>>
>>this
>>
>>>>bug.
>>>>
>>>>--
>>>>Jean-Sebastien
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>>
>>>--
>>>Luciano Resende
>>>Apache Tuscany Committer
>>>http://people.apache.org/~lresende <http://people.apache.org/%7Elresende
>>>
>>>http://lresende.blogspot.com/
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>So several points coming out here. Let me try and catch them (in no
>>
>>particular order)
>>
>>Issue1 - we have more than one piece of code in Tuscany that generates
>>WSDL
>>(using underlying Axis2 tools but possibly in different ways)
>>Solution
>> Do WSDL generation in one place.
>>
>>Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of
>>wrapped which we have set out to support
>>Solution1
>> get Axis to fix it
>>Solution2 (stop gap)
>> post process the generated WSDL to correct it for Tuscany
>>
>>Issue3 - Service providers and consumer outside of Tuscany may generate
>>broken WSDL and reasonably expect their messages to work with Tuscany
>>Solution
>> There is a fix available to make inbound Axis2 processing lax to the
>>extent that it handlse Axis2 version of a null parameter operation
>> A fix is required for void return values
>>
>>It sounds like
>>
>>We could address Issue1 if it's possible
>> - need Luciano/Ant to say if this is possible and/or worth it
>>
>>We should address Issue2 Solution 1
>> - well get it moving at least
>>
>>We could address Issue2 Solution2
>> - I quite like the idea of producing the correct WSDL as we see it but
>>there is concern that we don't know if it we will break someone who relies
>>on the WSDL the way axis produces it. This makes the assumption that it
>>works for more people in its current form that it does in it's fixed up
>>form. Which in turn is based on people being happy using Axis2. Warrants a
>>bit of investigation.
>>
>>We should address Issue3
>
>
>
> I agree this should be brought up with the Axis2 guys before we go ahead and
> try to patch the wsdl. Maybe there is some reason its this way, maybe there
> is some option we're not using to get the wsdl the way we want. Axis2 has
> passed the JAXWS TCK and its had lots of interop testing and fixing done
> with lots of other systems, and they are the WS experts not us.
>
WS-I has a fair bit of experience with interop as well, and the SCA
spec for the Web Service binding says that only WS-I compliant mapping is
supported. The input I have received from one of the WS-I Basic Profile
authors (see my post from yesterday) is that an approach that uses
soap:action to disambiguate between different operations without
parameters is not WS-I compliant.
I agree that we have to be able to support native Axis2 interop (see my
comments below), but that's not the whole picture.
> I think the ultimate goal should be for SDO to be a proper Axis2 supported
> data binding just as other data bindings like adb, jibx and jaxb are. That
> way we can just remove the tools from Tuscany and have all the code in
> axis2. That will make our lives much easier not having to keep copying and
> patching the axis2 code, and it will help encourage the use of SDO.
>
I have not suggested copying and patching the Axis2 code. There are
serious maintenance issues with this, as you point out. A postprocessing
approach (where this is practical) should be much more reliable.
> We can't get that done by our 1.0 though so need something for now. We're
> not planing on attempting to pass the jaxws tck so i'd be happy if we just
> have something that works even if we suspect it may not be fully jaxws
> compliant as long as Tuscany services and references can talk to each other
> or to native axis2 clients and services. So i still quite like the fix that
> Simon L proposed early on in this thread.
>
> ...ant
>
I have now got my test case working to show Tuscany services and
references talking to each other using an augmented version of the
WSDL generated by Axis2 Java2WSDL (hand edited currently) with an
empty wrapper for the no parameters case. There's a small fix
needed in the databinding framework to deal with void return types
when there are no parameters. I have a patch and I'll post it soon.
The next step is to see whether this works for Tuscany services and
references talking to native Axis2 clients and services. I'll look
into this later and post my findings tomorrow.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by ant elder <an...@gmail.com>.
On 9/5/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > Note that we have a similar issue that I'm looking at under the
> > wsdl2java tooling, described in this post [1]
> >
> > [1]
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
> >
> > On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > Jean-Sebastien Delfino wrote:
> > > > [snip]
> > > > Simon Laws wrote:
> > > >> I've done a bit more investigation now. For the signature
> > > >>
> > > >> String foo()
> > > >>
> > > >> Axis2 Java2WSDL generates
> > > >>
> > > >> <wsdl:types>
> > > >> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
> > > >> attributeFormDefault="qualified"
> > > >> elementFormDefault="qualified"
> > > >> targetNamespace=" http://test/xsd">
> > > >> <xs:element name="fooResponse">
> > > >> <xs:complexType>
> > > >> <xs:sequence>
> > > >> <xs:element name="return" nillable="true"
> > > >> type="xs:string" />
> > > >> </xs:sequence>
> > > >> </xs:complexType>
> > > >> </xs:element>
> > > >> </xs:schema>
> > > >> </wsdl:types>
> > > >> <wsdl:message name="fooMessage" />
> > > >> <wsdl:message name="fooResponseMessage">
> > > >> <wsdl:part name="part1" element="ns:fooResponse" />
> > > >> </wsdl:message>
> > > >>
> > > >>
> > > >
> > > > I'm trying to understand the overall picture before choosing a side:
> > > > - tolerate what Axis2 generates in our isWrapped() algorithm?
> > > > - or fix the WSDL after it's generated by Axis2?
> > > >
> > > > I have the following two questions:
> > > > 1) Is it true that the above WSDL has no chance to work at all as it
> > > > doesn't allow the "foo" operation to be sent at all (since there is
> no
> >
> > > > "foo" element to carry it)?
> > > >
> > > > 2) Could you please paste the entire WSDL? including the generated
> > > > binding and service+port? I believe that it'll help answer question
> > (1).
> > > >
> > > > Thanks
> > > >
> > >
> > > OK, looks like the answer to your question was already in your post, I
> > > should have read it better. In this case, it works with SOAP action.
> > >
> > > I think it's better to tolerate that (incorrect) behavior from Axis2
> for
> > > now, as:
> > > (a) I don't think we'll be able to patch all WSDLs that may be
> generated
> > > by users with the Axis2 tools out of our control
> > > (b) this is a workaround anyway, and a "tolerating" workaround is not
> > > worse than a "patching" workaround, actually it is probably better as
> it
> > > won't introduce any other side effects
> > >
> > > I also think that we need to open an Axis2 JIRA to report and track
> this
> > > bug.
> > >
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende
> >
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > So several points coming out here. Let me try and catch them (in no
> particular order)
>
> Issue1 - we have more than one piece of code in Tuscany that generates
> WSDL
> (using underlying Axis2 tools but possibly in different ways)
> Solution
> Do WSDL generation in one place.
>
> Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of
> wrapped which we have set out to support
> Solution1
> get Axis to fix it
> Solution2 (stop gap)
> post process the generated WSDL to correct it for Tuscany
>
> Issue3 - Service providers and consumer outside of Tuscany may generate
> broken WSDL and reasonably expect their messages to work with Tuscany
> Solution
> There is a fix available to make inbound Axis2 processing lax to the
> extent that it handlse Axis2 version of a null parameter operation
> A fix is required for void return values
>
> It sounds like
>
> We could address Issue1 if it's possible
> - need Luciano/Ant to say if this is possible and/or worth it
>
> We should address Issue2 Solution 1
> - well get it moving at least
>
> We could address Issue2 Solution2
> - I quite like the idea of producing the correct WSDL as we see it but
> there is concern that we don't know if it we will break someone who relies
> on the WSDL the way axis produces it. This makes the assumption that it
> works for more people in its current form that it does in it's fixed up
> form. Which in turn is based on people being happy using Axis2. Warrants a
> bit of investigation.
>
> We should address Issue3
I agree this should be brought up with the Axis2 guys before we go ahead and
try to patch the wsdl. Maybe there is some reason its this way, maybe there
is some option we're not using to get the wsdl the way we want. Axis2 has
passed the JAXWS TCK and its had lots of interop testing and fixing done
with lots of other systems, and they are the WS experts not us.
I think the ultimate goal should be for SDO to be a proper Axis2 supported
data binding just as other data bindings like adb, jibx and jaxb are. That
way we can just remove the tools from Tuscany and have all the code in
axis2. That will make our lives much easier not having to keep copying and
patching the axis2 code, and it will help encourage the use of SDO.
We can't get that done by our 1.0 though so need something for now. We're
not planing on attempting to pass the jaxws tck so i'd be happy if we just
have something that works even if we suspect it may not be fully jaxws
compliant as long as Tuscany services and references can talk to each other
or to native axis2 clients and services. So i still quite like the fix that
Simon L proposed early on in this thread.
...ant
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/5/07, Luciano Resende <lu...@gmail.com> wrote:
>
> Note that we have a similar issue that I'm looking at under the
> wsdl2java tooling, described in this post [1]
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
>
> On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > Jean-Sebastien Delfino wrote:
> > > [snip]
> > > Simon Laws wrote:
> > >> I've done a bit more investigation now. For the signature
> > >>
> > >> String foo()
> > >>
> > >> Axis2 Java2WSDL generates
> > >>
> > >> <wsdl:types>
> > >> <xs:schema xmlns:xs=" http://www.w3.org/2001/XMLSchema"
> > >> attributeFormDefault="qualified"
> > >> elementFormDefault="qualified"
> > >> targetNamespace=" http://test/xsd">
> > >> <xs:element name="fooResponse">
> > >> <xs:complexType>
> > >> <xs:sequence>
> > >> <xs:element name="return" nillable="true"
> > >> type="xs:string" />
> > >> </xs:sequence>
> > >> </xs:complexType>
> > >> </xs:element>
> > >> </xs:schema>
> > >> </wsdl:types>
> > >> <wsdl:message name="fooMessage" />
> > >> <wsdl:message name="fooResponseMessage">
> > >> <wsdl:part name="part1" element="ns:fooResponse" />
> > >> </wsdl:message>
> > >>
> > >>
> > >
> > > I'm trying to understand the overall picture before choosing a side:
> > > - tolerate what Axis2 generates in our isWrapped() algorithm?
> > > - or fix the WSDL after it's generated by Axis2?
> > >
> > > I have the following two questions:
> > > 1) Is it true that the above WSDL has no chance to work at all as it
> > > doesn't allow the "foo" operation to be sent at all (since there is no
>
> > > "foo" element to carry it)?
> > >
> > > 2) Could you please paste the entire WSDL? including the generated
> > > binding and service+port? I believe that it'll help answer question
> (1).
> > >
> > > Thanks
> > >
> >
> > OK, looks like the answer to your question was already in your post, I
> > should have read it better. In this case, it works with SOAP action.
> >
> > I think it's better to tolerate that (incorrect) behavior from Axis2 for
> > now, as:
> > (a) I don't think we'll be able to patch all WSDLs that may be generated
> > by users with the Axis2 tools out of our control
> > (b) this is a workaround anyway, and a "tolerating" workaround is not
> > worse than a "patching" workaround, actually it is probably better as it
> > won't introduce any other side effects
> >
> > I also think that we need to open an Axis2 JIRA to report and track this
> > bug.
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> So several points coming out here. Let me try and catch them (in no
particular order)
Issue1 - we have more than one piece of code in Tuscany that generates WSDL
(using underlying Axis2 tools but possibly in different ways)
Solution
Do WSDL generation in one place.
Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of
wrapped which we have set out to support
Solution1
get Axis to fix it
Solution2 (stop gap)
post process the generated WSDL to correct it for Tuscany
Issue3 - Service providers and consumer outside of Tuscany may generate
broken WSDL and reasonably expect their messages to work with Tuscany
Solution
There is a fix available to make inbound Axis2 processing lax to the
extent that it handlse Axis2 version of a null parameter operation
A fix is required for void return values
It sounds like
We could address Issue1 if it's possible
- need Luciano/Ant to say if this is possible and/or worth it
We should address Issue2 Solution 1
- well get it moving at least
We could address Issue2 Solution2
- I quite like the idea of producing the correct WSDL as we see it but
there is concern that we don't know if it we will break someone who relies
on the WSDL the way axis produces it. This makes the assumption that it
works for more people in its current form that it does in it's fixed up
form. Which in turn is based on people being happy using Axis2. Warrants a
bit of investigation.
We should address Issue3
Simon
Re: Wrapper style test in WSDL processing?
Posted by Luciano Resende <lu...@gmail.com>.
Note that we have a similar issue that I'm looking at under the
wsdl2java tooling, described in this post [1]
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html
On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Jean-Sebastien Delfino wrote:
> > [snip]
> > Simon Laws wrote:
> >> I've done a bit more investigation now. For the signature
> >>
> >> String foo()
> >>
> >> Axis2 Java2WSDL generates
> >>
> >> <wsdl:types>
> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> >> attributeFormDefault="qualified"
> >> elementFormDefault="qualified"
> >> targetNamespace="http://test/xsd">
> >> <xs:element name="fooResponse">
> >> <xs:complexType>
> >> <xs:sequence>
> >> <xs:element name="return" nillable="true"
> >> type="xs:string" />
> >> </xs:sequence>
> >> </xs:complexType>
> >> </xs:element>
> >> </xs:schema>
> >> </wsdl:types>
> >> <wsdl:message name="fooMessage" />
> >> <wsdl:message name="fooResponseMessage">
> >> <wsdl:part name="part1" element="ns:fooResponse" />
> >> </wsdl:message>
> >>
> >>
> >
> > I'm trying to understand the overall picture before choosing a side:
> > - tolerate what Axis2 generates in our isWrapped() algorithm?
> > - or fix the WSDL after it's generated by Axis2?
> >
> > I have the following two questions:
> > 1) Is it true that the above WSDL has no chance to work at all as it
> > doesn't allow the "foo" operation to be sent at all (since there is no
> > "foo" element to carry it)?
> >
> > 2) Could you please paste the entire WSDL? including the generated
> > binding and service+port? I believe that it'll help answer question (1).
> >
> > Thanks
> >
>
> OK, looks like the answer to your question was already in your post, I
> should have read it better. In this case, it works with SOAP action.
>
> I think it's better to tolerate that (incorrect) behavior from Axis2 for
> now, as:
> (a) I don't think we'll be able to patch all WSDLs that may be generated
> by users with the Axis2 tools out of our control
> (b) this is a workaround anyway, and a "tolerating" workaround is not
> worse than a "patching" workaround, actually it is probably better as it
> won't introduce any other side effects
>
> I also think that we need to open an Axis2 JIRA to report and track this
> bug.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> [snip]
> Simon Laws wrote:
>> I've done a bit more investigation now. For the signature
>>
>> String foo()
>>
>> Axis2 Java2WSDL generates
>>
>> <wsdl:types>
>> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
>> attributeFormDefault="qualified"
>> elementFormDefault="qualified"
>> targetNamespace="http://test/xsd">
>> <xs:element name="fooResponse">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="return" nillable="true"
>> type="xs:string" />
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>> </xs:schema>
>> </wsdl:types>
>> <wsdl:message name="fooMessage" />
>> <wsdl:message name="fooResponseMessage">
>> <wsdl:part name="part1" element="ns:fooResponse" />
>> </wsdl:message>
>>
>>
>
> I'm trying to understand the overall picture before choosing a side:
> - tolerate what Axis2 generates in our isWrapped() algorithm?
> - or fix the WSDL after it's generated by Axis2?
>
> I have the following two questions:
> 1) Is it true that the above WSDL has no chance to work at all as it
> doesn't allow the "foo" operation to be sent at all (since there is no
> "foo" element to carry it)?
>
> 2) Could you please paste the entire WSDL? including the generated
> binding and service+port? I believe that it'll help answer question (1).
>
> Thanks
>
OK, looks like the answer to your question was already in your post, I
should have read it better. In this case, it works with SOAP action.
I think it's better to tolerate that (incorrect) behavior from Axis2 for
now, as:
(a) I don't think we'll be able to patch all WSDLs that may be generated
by users with the Axis2 tools out of our control
(b) this is a workaround anyway, and a "tolerating" workaround is not
worse than a "patching" workaround, actually it is probably better as it
won't introduce any other side effects
I also think that we need to open an Axis2 JIRA to report and track this
bug.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > <snip>
> >
> > I'm trying to understand the overall picture before choosing a side:
> >
> >> - tolerate what Axis2 generates in our isWrapped() algorithm?
> >>
> >
> >
> > Is it really just the wsdl that Axis2 (1.2) generates? What about
> anyone
> > using an existing wsdl that is wrapped style but may not precisely match
> the
> > jaxws definition of wrapped?
> >
> > ...ant
> >
> >
>
> Do you have a specific WSDL pattern in mind?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> This was the WSDL from the axis2 java2wsdl tool.
<wsdl:definitions xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:ns="http://test/xsd" xmlns:axis2="http://test"
targetNamespace="http://test">
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http://test/xsd">
<xs:element name="fooResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" nillable="true"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="fooMessage" />
<wsdl:message name="fooResponseMessage">
<wsdl:part name="part1" element="ns:fooResponse" />
</wsdl:message>
<wsdl:portType name="TestServicePortType">
<wsdl:operation name="foo">
<wsdl:input
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
wsaw:Action="urn:foo" message="axis2:fooMessage" />
<wsdl:output
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
message="axis2:fooResponseMessage" wsaw:Action="urn:foo" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="TestServiceSOAP11Binding"
type="axis2:TestServicePortType">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<wsdl:operation name="foo">
<soap:operation soapAction="urn:foo" style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="TestServiceSOAP12Binding"
type="axis2:TestServicePortType">
<soap12:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<wsdl:operation name="foo">
<soap12:operation soapAction="urn:foo" style="document" />
<wsdl:input>
<soap12:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap12:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="TestService">
<wsdl:port name="TestServiceSOAP11port"
binding="axis2:TestServiceSOAP11Binding">
<soap:address
location="http://localhost:8080/axis2/services/TestService"
/>
</wsdl:port>
<wsdl:port name="TestServiceSOAP12port"
binding="axis2:TestServiceSOAP12Binding">
<soap12:address
location="http://localhost:8080/axis2/services/TestService"
/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Simon
Re: Wrapper style test in WSDL processing?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> <snip>
>
> I'm trying to understand the overall picture before choosing a side:
>
>> - tolerate what Axis2 generates in our isWrapped() algorithm?
>>
>
>
> Is it really just the wsdl that Axis2 (1.2) generates? What about anyone
> using an existing wsdl that is wrapped style but may not precisely match the
> jaxws definition of wrapped?
>
> ...ant
>
>
Do you have a specific WSDL pattern in mind?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by ant elder <an...@gmail.com>.
On 9/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
<snip>
I'm trying to understand the overall picture before choosing a side:
> - tolerate what Axis2 generates in our isWrapped() algorithm?
Is it really just the wsdl that Axis2 (1.2) generates? What about anyone
using an existing wsdl that is wrapped style but may not precisely match the
jaxws definition of wrapped?
...ant
Re: Wrapper style test in WSDL processing?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
> I've done a bit more investigation now. For the signature
>
> String foo()
>
> Axis2 Java2WSDL generates
>
> <wsdl:types>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> attributeFormDefault="qualified" elementFormDefault="qualified"
> targetNamespace="http://test/xsd">
> <xs:element name="fooResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="return" nillable="true"
> type="xs:string" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:schema>
> </wsdl:types>
> <wsdl:message name="fooMessage" />
> <wsdl:message name="fooResponseMessage">
> <wsdl:part name="part1" element="ns:fooResponse" />
> </wsdl:message>
>
>
I'm trying to understand the overall picture before choosing a side:
- tolerate what Axis2 generates in our isWrapped() algorithm?
- or fix the WSDL after it's generated by Axis2?
I have the following two questions:
1) Is it true that the above WSDL has no chance to work at all as it
doesn't allow the "foo" operation to be sent at all (since there is no
"foo" element to carry it)?
2) Could you please paste the entire WSDL? including the generated
binding and service+port? I believe that it'll help answer question (1).
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Wrapper style test in WSDL processing?
Posted by ant elder <an...@gmail.com>.
Axis2 has passed the jaxws tck now so either the tck doesn't check this or
we're using java2wsdl incorrectly. If it is a bug how about tolerating this
in our code for now till Axis2 gets fixed? I.e the apply the changes
suggested below. This seems better to me that having yet another patch to
java2wsdl in Tuscany as its becoming a maintenance nightmare with these
local changes we have making it really difficult to change Axis2 releases.
...ant
On 9/2/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 9/2/07, Raymond Feng <en...@gmail.com> wrote:
> >
> > I don't think the Axis2 generates a valid wrapper-style WSDL in this
> case
> > (even though the WSDL itself is legal). It violates rule i & ii as it
> has
> > the input message fooMessage doesn't have any part.
> >
> > The following is quoted from the JAX-WS 2.0 spec:
> >
> > 2.3.1.2 Wrapper Style
> > A WSDL operation qualifies for wrapper style mapping only if the
> following
> > criteria are met:
> > (i) The operation's input and output messages (if present) each contain
> > only
> > a single part
> > (ii) The input message part refers to a global element declaration whose
> > localname is equal to the operation
> > name
> > (iii) The output message part refers to a global element declaration
> > (iv) The elements referred to by the input and output message parts
> > (henceforth referred to as wrapper
> > elements) are both complex types defined using the xsd:sequence
> compositor
> > (v) The wrapper elements only contain child elements, they must not
> > contain
> > other structures such as
> > wildcards (element or attribute), xsd:choice, substitution groups
> (element
> > references are not permitted)
> > or attributes; furthermore, they must not be nillable.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Simon Laws" <si...@googlemail.com>
> > To: <tu...@ws.apache.org>
> > Sent: Sunday, September 02, 2007 7:41 AM
> > Subject: Re: Wrapper style test in WSDL processing?
> >
> >
> > > On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> > >>
> > >>
> > >>
> > >> On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > The operation.getInput() cannot be null to qualify for the wrapper
> > >> > style.
> > >> > There must be a part in the input message corresponding to the
> > >> > operation
> > >> > name:
> > >> >
> > >> > input
> > >> > --- message
> > >> > --- part (only one part)
> > >> > --- element (the element name should be the same as
> > the
> > >> > operation name)
> > >> >
> > >> > The element should look like this:
> > >> >
> > >> > <element name="myMethod">
> > >> > <complexType>
> > >> > <sequence/> <!-- an empty sequence -->
> > >> > </complexType>
> > >> > </element>
> > >> >
> > >> > Thanks,
> > >> > Raymond
> > >> >
> > >> > ----- Original Message -----
> > >> > From: "Simon Laws" <si...@googlemail.com>
> > >> > To: "tuscany-dev" <tu...@ws.apache.org>
> > >> > Sent: Friday, August 31, 2007 10:34 AM
> > >> > Subject: Wrapper style test in WSDL processing?
> > >> >
> > >> >
> > >> > > There is a test to determine whether a WSDL operation follows the
> > >> > > "wrapped"
> > >> > > style in accordance with JAX-WS 2.0 spec. See
> > >> > > WSDLOperationIntrospectorImpl
> > >> > > (
> > >> > >
> > >> >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> > >> > > )
> > >> > >
> > >> > > The code is currently
> > >> > >
> > >> > > public boolean isWrapperStyle() throws InvalidWSDLException {
> > >> > > if (wrapperStyle == null) {
> > >> > > wrapperStyle =
> > >> > > wrapper.getInputChildElements() != null && (
> > >> > > operation.getOutput() == null || wrapper
> > >> > > .getOutputChildElements() != null);
> > >> > > }
> > >> > > return wrapperStyle;
> > >> > > }
> > >> > >
> > >> > > Which doesn't seem to cater for the case where there may be no
> > input
> > >> > > parameters. I'm diving into this code now to see if I can work
> out
> > >> > what it
> > >> > > means but if anyone has any insight I would appreciate it.
> > >> > >
> > >> > > Needless to say I have a scenario where I am trying to auto
> > generate
> > >> > WSDL
> > >> > > for a method with the signature
> > >> > >
> > >> > > String myMethod()
> > >> > >
> > >> > > And it's complaining that it's not wrapped.
> > >> > >
> > >> > > Simon
> > >> > >
> > >> >
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> >
> > >> > What you are saying sounds right to me, I.e. you can validly have
> no
> > >> parameters in your method but in this case it should build an empty
> > >> sequence
> > >>
> > >>
> > >> <element name="myMethod">
> > >> <complexType>
> > >> <sequence/> <!-- an empty sequence -->
> > >> </complexType>
> > >> </element>
> > >>
> > >> And have this as the single input type. I'm deeper into the code now
> > >> looking for why this isn't the case.
> > >>
> > >> Thanks Raymond
> > >>
> > >> Simon
> > >>
> > > I've done a bit more investigation now. For the signature
> > >
> > > String foo()
> > >
> > > Axis2 Java2WSDL generates
> > >
> > > <wsdl:types>
> > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > > attributeFormDefault="qualified"
> > elementFormDefault="qualified"
> > > targetNamespace="http://test/xsd">
> > > <xs:element name="fooResponse">
> > > <xs:complexType>
> > > <xs:sequence>
> > > <xs:element name="return" nillable="true"
> > > type="xs:string" />
> > > </xs:sequence>
> > > </xs:complexType>
> > > </xs:element>
> > > </xs:schema>
> > > </wsdl:types>
> > > <wsdl:message name="fooMessage" />
> > > <wsdl:message name="fooResponseMessage">
> > > <wsdl:part name="part1" element="ns:fooResponse" />
> > > </wsdl:message>
> > >
> > > So in our code when it comes to testing for wrapped it returns false
> > > because
> > > this doesn't match the algorithm that was presented earlier in this
> > > thread,
> > > i.e. there is no part of the input message corresponding to the
> message
> > > name. So when you try this in Tuscany is throws an exception saying
> that
> > > the
> > > operation is not wrapped.
> > >
> > > It would be inconvenient for us to not support operations with no
> > > parameters. As the wsdl generation process assumes that the target
> > > operations will be generated as wrapped operations here's what I did..
> > >
> > > 1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
> > to
> > > read.
> > >
> > > public boolean isWrapperStyle() throws InvalidWSDLException {
> > > if (wrapperStyle == null) {
> > > wrapperStyle =
> > >
> > > (operation.getInput().getMessage().getParts().values().size()
> > > == 0 ||wrapper.getInputChildElements() != null) &&
> > > (operation.getOutput() == null ||
> > > wrapper.getOutputChildElements() != null);
> > > }
> > > return wrapperStyle;
> > > }
> > >
> > > I.e. I'm letting it pass if there are no input parts at all which I
> > > believe
> > > is valid according the the JAX-WS 2.0 spec
> > >
> > > 2/ Fixed the getWrapperInfo method to take account of the case where
> > there
> > > are no input params
> > >
> > > if (in != null) {
> > > for (XmlSchemaElement e : getInputChildElements())
> {
> > > inChildren.add(getElementInfo(e));
> > > }
> > > }
> > >
> > > 3/ Fixed the Axis2 binding to properly deal with the case when no
> > > parameters
> > > are present in Axis2ServiceInOutSyncMessageReceiver.
> > >
> > > public void invokeBusinessLogic(MessageContext inMC, MessageContext
> > > outMC) throws AxisFault {
> > > try {
> > > OMElement requestOM = inMC.getEnvelope
> > > ().getBody().getFirstElement();
> > > Object[] args = null;
> > >
> > > if (requestOM != null) {
> > > args = new Object[] {requestOM};
> > > }
> > >
> > > The Axis2ServiceInMessageReceiver needs the same fix if we go with
> this.
> > >
> > > This works with the forward message relying on the soap action to
> > > indentify
> > > the correct operation.
> > >
> > > I haven't checked this in as the code seems to have been carefully
> > crafted
> > > to assume that there will always be an input parameter. Can someone
> > > explain
> > > why this is thought to be the case?
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > Mmm, I think I'm interpreting the "(if present)" wrongly then. Anyhow it
> still leaves us with a bit of a problem. I just gave it a spin in
> Axis2-1.3.
> and get the same result so we will likely have to do our own fix in the
> short term.
>
> Simon
>
Re: Wrapper style test in WSDL processing?
Posted by Simon Laws <si...@googlemail.com>.
On 9/2/07, Raymond Feng <en...@gmail.com> wrote:
>
> I don't think the Axis2 generates a valid wrapper-style WSDL in this case
> (even though the WSDL itself is legal). It violates rule i & ii as it has
> the input message fooMessage doesn't have any part.
>
> The following is quoted from the JAX-WS 2.0 spec:
>
> 2.3.1.2 Wrapper Style
> A WSDL operation qualifies for wrapper style mapping only if the following
> criteria are met:
> (i) The operation's input and output messages (if present) each contain
> only
> a single part
> (ii) The input message part refers to a global element declaration whose
> localname is equal to the operation
> name
> (iii) The output message part refers to a global element declaration
> (iv) The elements referred to by the input and output message parts
> (henceforth referred to as wrapper
> elements) are both complex types defined using the xsd:sequence compositor
> (v) The wrapper elements only contain child elements, they must not
> contain
> other structures such as
> wildcards (element or attribute), xsd:choice, substitution groups (element
> references are not permitted)
> or attributes; furthermore, they must not be nillable.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Simon Laws" <si...@googlemail.com>
> To: <tu...@ws.apache.org>
> Sent: Sunday, September 02, 2007 7:41 AM
> Subject: Re: Wrapper style test in WSDL processing?
>
>
> > On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
> >>
> >>
> >>
> >> On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > The operation.getInput() cannot be null to qualify for the wrapper
> >> > style.
> >> > There must be a part in the input message corresponding to the
> >> > operation
> >> > name:
> >> >
> >> > input
> >> > --- message
> >> > --- part (only one part)
> >> > --- element (the element name should be the same as
> the
> >> > operation name)
> >> >
> >> > The element should look like this:
> >> >
> >> > <element name="myMethod">
> >> > <complexType>
> >> > <sequence/> <!-- an empty sequence -->
> >> > </complexType>
> >> > </element>
> >> >
> >> > Thanks,
> >> > Raymond
> >> >
> >> > ----- Original Message -----
> >> > From: "Simon Laws" <si...@googlemail.com>
> >> > To: "tuscany-dev" <tu...@ws.apache.org>
> >> > Sent: Friday, August 31, 2007 10:34 AM
> >> > Subject: Wrapper style test in WSDL processing?
> >> >
> >> >
> >> > > There is a test to determine whether a WSDL operation follows the
> >> > > "wrapped"
> >> > > style in accordance with JAX-WS 2.0 spec. See
> >> > > WSDLOperationIntrospectorImpl
> >> > > (
> >> > >
> >> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> >> > > )
> >> > >
> >> > > The code is currently
> >> > >
> >> > > public boolean isWrapperStyle() throws InvalidWSDLException {
> >> > > if (wrapperStyle == null) {
> >> > > wrapperStyle =
> >> > > wrapper.getInputChildElements() != null && (
> >> > > operation.getOutput() == null || wrapper
> >> > > .getOutputChildElements() != null);
> >> > > }
> >> > > return wrapperStyle;
> >> > > }
> >> > >
> >> > > Which doesn't seem to cater for the case where there may be no
> input
> >> > > parameters. I'm diving into this code now to see if I can work out
> >> > what it
> >> > > means but if anyone has any insight I would appreciate it.
> >> > >
> >> > > Needless to say I have a scenario where I am trying to auto
> generate
> >> > WSDL
> >> > > for a method with the signature
> >> > >
> >> > > String myMethod()
> >> > >
> >> > > And it's complaining that it's not wrapped.
> >> > >
> >> > > Simon
> >> > >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> > What you are saying sounds right to me, I.e. you can validly have no
> >> parameters in your method but in this case it should build an empty
> >> sequence
> >>
> >>
> >> <element name="myMethod">
> >> <complexType>
> >> <sequence/> <!-- an empty sequence -->
> >> </complexType>
> >> </element>
> >>
> >> And have this as the single input type. I'm deeper into the code now
> >> looking for why this isn't the case.
> >>
> >> Thanks Raymond
> >>
> >> Simon
> >>
> > I've done a bit more investigation now. For the signature
> >
> > String foo()
> >
> > Axis2 Java2WSDL generates
> >
> > <wsdl:types>
> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> > attributeFormDefault="qualified"
> elementFormDefault="qualified"
> > targetNamespace="http://test/xsd">
> > <xs:element name="fooResponse">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="return" nillable="true"
> > type="xs:string" />
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> > </xs:schema>
> > </wsdl:types>
> > <wsdl:message name="fooMessage" />
> > <wsdl:message name="fooResponseMessage">
> > <wsdl:part name="part1" element="ns:fooResponse" />
> > </wsdl:message>
> >
> > So in our code when it comes to testing for wrapped it returns false
> > because
> > this doesn't match the algorithm that was presented earlier in this
> > thread,
> > i.e. there is no part of the input message corresponding to the message
> > name. So when you try this in Tuscany is throws an exception saying that
> > the
> > operation is not wrapped.
> >
> > It would be inconvenient for us to not support operations with no
> > parameters. As the wsdl generation process assumes that the target
> > operations will be generated as wrapped operations here's what I did..
> >
> > 1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl)
> to
> > read.
> >
> > public boolean isWrapperStyle() throws InvalidWSDLException {
> > if (wrapperStyle == null) {
> > wrapperStyle =
> >
> > (operation.getInput().getMessage().getParts().values().size()
> > == 0 ||wrapper.getInputChildElements() != null) &&
> > (operation.getOutput() == null ||
> > wrapper.getOutputChildElements() != null);
> > }
> > return wrapperStyle;
> > }
> >
> > I.e. I'm letting it pass if there are no input parts at all which I
> > believe
> > is valid according the the JAX-WS 2.0 spec
> >
> > 2/ Fixed the getWrapperInfo method to take account of the case where
> there
> > are no input params
> >
> > if (in != null) {
> > for (XmlSchemaElement e : getInputChildElements()) {
> > inChildren.add(getElementInfo(e));
> > }
> > }
> >
> > 3/ Fixed the Axis2 binding to properly deal with the case when no
> > parameters
> > are present in Axis2ServiceInOutSyncMessageReceiver.
> >
> > public void invokeBusinessLogic(MessageContext inMC, MessageContext
> > outMC) throws AxisFault {
> > try {
> > OMElement requestOM = inMC.getEnvelope
> > ().getBody().getFirstElement();
> > Object[] args = null;
> >
> > if (requestOM != null) {
> > args = new Object[] {requestOM};
> > }
> >
> > The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
> >
> > This works with the forward message relying on the soap action to
> > indentify
> > the correct operation.
> >
> > I haven't checked this in as the code seems to have been carefully
> crafted
> > to assume that there will always be an input parameter. Can someone
> > explain
> > why this is thought to be the case?
> >
> > Regards
> >
> > Simon
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Mmm, I think I'm interpreting the "(if present)" wrongly then. Anyhow it
still leaves us with a bit of a problem. I just gave it a spin in Axis2-1.3.
and get the same result so we will likely have to do our own fix in the
short term.
Simon
Re: Wrapper style test in WSDL processing?
Posted by Raymond Feng <en...@gmail.com>.
I don't think the Axis2 generates a valid wrapper-style WSDL in this case
(even though the WSDL itself is legal). It violates rule i & ii as it has
the input message fooMessage doesn't have any part.
The following is quoted from the JAX-WS 2.0 spec:
2.3.1.2 Wrapper Style
A WSDL operation qualifies for wrapper style mapping only if the following
criteria are met:
(i) The operation's input and output messages (if present) each contain only
a single part
(ii) The input message part refers to a global element declaration whose
localname is equal to the operation
name
(iii) The output message part refers to a global element declaration
(iv) The elements referred to by the input and output message parts
(henceforth referred to as wrapper
elements) are both complex types defined using the xsd:sequence compositor
(v) The wrapper elements only contain child elements, they must not contain
other structures such as
wildcards (element or attribute), xsd:choice, substitution groups (element
references are not permitted)
or attributes; furthermore, they must not be nillable.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: <tu...@ws.apache.org>
Sent: Sunday, September 02, 2007 7:41 AM
Subject: Re: Wrapper style test in WSDL processing?
> On 8/31/07, Simon Laws <si...@googlemail.com> wrote:
>>
>>
>>
>> On 8/31/07, Raymond Feng <en...@gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > The operation.getInput() cannot be null to qualify for the wrapper
>> > style.
>> > There must be a part in the input message corresponding to the
>> > operation
>> > name:
>> >
>> > input
>> > --- message
>> > --- part (only one part)
>> > --- element (the element name should be the same as the
>> > operation name)
>> >
>> > The element should look like this:
>> >
>> > <element name="myMethod">
>> > <complexType>
>> > <sequence/> <!-- an empty sequence -->
>> > </complexType>
>> > </element>
>> >
>> > Thanks,
>> > Raymond
>> >
>> > ----- Original Message -----
>> > From: "Simon Laws" <si...@googlemail.com>
>> > To: "tuscany-dev" <tu...@ws.apache.org>
>> > Sent: Friday, August 31, 2007 10:34 AM
>> > Subject: Wrapper style test in WSDL processing?
>> >
>> >
>> > > There is a test to determine whether a WSDL operation follows the
>> > > "wrapped"
>> > > style in accordance with JAX-WS 2.0 spec. See
>> > > WSDLOperationIntrospectorImpl
>> > > (
>> > >
>> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
>> > > )
>> > >
>> > > The code is currently
>> > >
>> > > public boolean isWrapperStyle() throws InvalidWSDLException {
>> > > if (wrapperStyle == null) {
>> > > wrapperStyle =
>> > > wrapper.getInputChildElements() != null && (
>> > > operation.getOutput() == null || wrapper
>> > > .getOutputChildElements() != null);
>> > > }
>> > > return wrapperStyle;
>> > > }
>> > >
>> > > Which doesn't seem to cater for the case where there may be no input
>> > > parameters. I'm diving into this code now to see if I can work out
>> > what it
>> > > means but if anyone has any insight I would appreciate it.
>> > >
>> > > Needless to say I have a scenario where I am trying to auto generate
>> > WSDL
>> > > for a method with the signature
>> > >
>> > > String myMethod()
>> > >
>> > > And it's complaining that it's not wrapped.
>> > >
>> > > Simon
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> > What you are saying sounds right to me, I.e. you can validly have no
>> parameters in your method but in this case it should build an empty
>> sequence
>>
>>
>> <element name="myMethod">
>> <complexType>
>> <sequence/> <!-- an empty sequence -->
>> </complexType>
>> </element>
>>
>> And have this as the single input type. I'm deeper into the code now
>> looking for why this isn't the case.
>>
>> Thanks Raymond
>>
>> Simon
>>
> I've done a bit more investigation now. For the signature
>
> String foo()
>
> Axis2 Java2WSDL generates
>
> <wsdl:types>
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
> attributeFormDefault="qualified" elementFormDefault="qualified"
> targetNamespace="http://test/xsd">
> <xs:element name="fooResponse">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="return" nillable="true"
> type="xs:string" />
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> </xs:schema>
> </wsdl:types>
> <wsdl:message name="fooMessage" />
> <wsdl:message name="fooResponseMessage">
> <wsdl:part name="part1" element="ns:fooResponse" />
> </wsdl:message>
>
> So in our code when it comes to testing for wrapped it returns false
> because
> this doesn't match the algorithm that was presented earlier in this
> thread,
> i.e. there is no part of the input message corresponding to the message
> name. So when you try this in Tuscany is throws an exception saying that
> the
> operation is not wrapped.
>
> It would be inconvenient for us to not support operations with no
> parameters. As the wsdl generation process assumes that the target
> operations will be generated as wrapped operations here's what I did..
>
> 1/ Changed the isWrapperStyle test (in WSDLOperationIntrospectorImpl) to
> read.
>
> public boolean isWrapperStyle() throws InvalidWSDLException {
> if (wrapperStyle == null) {
> wrapperStyle =
>
> (operation.getInput().getMessage().getParts().values().size()
> == 0 ||wrapper.getInputChildElements() != null) &&
> (operation.getOutput() == null ||
> wrapper.getOutputChildElements() != null);
> }
> return wrapperStyle;
> }
>
> I.e. I'm letting it pass if there are no input parts at all which I
> believe
> is valid according the the JAX-WS 2.0 spec
>
> 2/ Fixed the getWrapperInfo method to take account of the case where there
> are no input params
>
> if (in != null) {
> for (XmlSchemaElement e : getInputChildElements()) {
> inChildren.add(getElementInfo(e));
> }
> }
>
> 3/ Fixed the Axis2 binding to properly deal with the case when no
> parameters
> are present in Axis2ServiceInOutSyncMessageReceiver.
>
> public void invokeBusinessLogic(MessageContext inMC, MessageContext
> outMC) throws AxisFault {
> try {
> OMElement requestOM = inMC.getEnvelope
> ().getBody().getFirstElement();
> Object[] args = null;
>
> if (requestOM != null) {
> args = new Object[] {requestOM};
> }
>
> The Axis2ServiceInMessageReceiver needs the same fix if we go with this.
>
> This works with the forward message relying on the soap action to
> indentify
> the correct operation.
>
> I haven't checked this in as the code seems to have been carefully crafted
> to assume that there will always be an input parameter. Can someone
> explain
> why this is thought to be the case?
>
> Regards
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org