You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Ias <ia...@tmax.co.kr> on 2004/04/13 04:59:01 UTC
RE: cvs commit: ws-axis/java/src/org/apache/axis/wsdl/fromJavaEmitter.java
> >What rationale does BP give for saying that putting namespace
> >declarations on soap:Body is a bad thing? Seems silly to me.
>
> See here:
>
> http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.h
> tml#refinement34313448
>
> R2716 A document-literal binding in a DESCRIPTION MUST NOT have the
> namespace attribute specified on contained soapbind:body,
> soapbind:header, soapbind:headerfault and soapbind:fault elements.
>
> ...
>
> In a document-literal SOAP binding, the serialized element child of
> the soap:Body gets its namespace from the targetNamespace of the
> schema that defines the element. Use of the namespace attribute of
> the soapbind:body element would override the element's namespace.
> This is not allowed by the Profile.
Good point. Thanks for leading Axis one step forward to WS-I BP 1.0. :-)
>
> Note that R2717 says the opposite for rpc/literal.
>
> BTW, I don't have an easy way to track the code changes. Are
> y'all creating tests for the bugs you close? That way the bug
> will never be reintroduced.
>
Testing Java->WSDL (and even WSDL->Java) seems quite tough in terms of
artifacts, not runtime workability. Probably we need a testing framework for
a WSDL processor, particularly, walking with WS-I Profiles. How about
inventing WSUnit (WebServicesUnit)? (Or already exists?) For example,
Having Java classes
->
Processing them to a WSDL
->
Checking certain assertions to the generated WSDL
and vice versa,
Having a WSDL
->
Processing it to Java classes
->
Checking certain assertions to the generated classes
Your comments and opinions are welcome all the time.
Regards,
Ias
Re: cvs commit: ws-axis/java/src/org/apache/axis/wsdl/fromJavaEmitter.java
Posted by Dan Diephouse <da...@envoisolutions.com>.
I find it works quite well to use xpath assertions:
assertValid("/soap:Envelope/soap:Body/some/node")
assertInvalid("//soap:fault")
...
etc.
Examples....
http://ivory.codehaus.org/soaplet/xref-test/org/codehaus/soaplet/velocity/TestSoapletTest.html
http://ivory.codehaus.org/soaplet/xref/org/codehaus/soaplet/velocity/TestSoaplet.html
Just an idea... Works great with WSDL too....
assertInvalid("/wsdl:definitions/wsdl:binding/wsdl:operation/wsdl:input/wsdlsoap:body[@namespace]")
- Dan
Ias wrote:
>>>What rationale does BP give for saying that putting namespace
>>>declarations on soap:Body is a bad thing? Seems silly to me.
>>>
>>>
>>See here:
>>
>>http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.h
>>tml#refinement34313448
>>
>> R2716 A document-literal binding in a DESCRIPTION MUST NOT have the
>> namespace attribute specified on contained soapbind:body,
>> soapbind:header, soapbind:headerfault and soapbind:fault elements.
>>
>> ...
>>
>> In a document-literal SOAP binding, the serialized element child of
>> the soap:Body gets its namespace from the targetNamespace of the
>> schema that defines the element. Use of the namespace attribute of
>> the soapbind:body element would override the element's namespace.
>> This is not allowed by the Profile.
>>
>>
>
>Good point. Thanks for leading Axis one step forward to WS-I BP 1.0. :-)
>
>
>
>>Note that R2717 says the opposite for rpc/literal.
>>
>>BTW, I don't have an easy way to track the code changes. Are
>>y'all creating tests for the bugs you close? That way the bug
>>will never be reintroduced.
>>
>>
>>
>
>Testing Java->WSDL (and even WSDL->Java) seems quite tough in terms of
>artifacts, not runtime workability. Probably we need a testing framework for
>a WSDL processor, particularly, walking with WS-I Profiles. How about
>inventing WSUnit (WebServicesUnit)? (Or already exists?) For example,
>
>Having Java classes
>->
>Processing them to a WSDL
>->
>Checking certain assertions to the generated WSDL
>
>and vice versa,
>
>Having a WSDL
>->
>Processing it to Java classes
>->
>Checking certain assertions to the generated classes
>
>Your comments and opinions are welcome all the time.
>
>Regards,
>
>Ias
>
>
>
--
Dan Diephouse
Envoi Solutions LLC
http://envoisolutions.com/people/dan
RE: cvs commit: ws-axis/java/src/org/apache/axis/wsdl/fromJavaEmitter.java
Posted by Davanum Srinivas <di...@yahoo.com>.
my +1 for the concept BUT first we need to get 1.2 out the door by passing the JAX-RPC TCK :)
-- dims
--- Ias <ia...@tmax.co.kr> wrote:
> > >What rationale does BP give for saying that putting namespace
> > >declarations on soap:Body is a bad thing? Seems silly to me.
> >
> > See here:
> >
> > http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.h
> > tml#refinement34313448
> >
> > R2716 A document-literal binding in a DESCRIPTION MUST NOT have the
> > namespace attribute specified on contained soapbind:body,
> > soapbind:header, soapbind:headerfault and soapbind:fault elements.
> >
> > ...
> >
> > In a document-literal SOAP binding, the serialized element child of
> > the soap:Body gets its namespace from the targetNamespace of the
> > schema that defines the element. Use of the namespace attribute of
> > the soapbind:body element would override the element's namespace.
> > This is not allowed by the Profile.
>
> Good point. Thanks for leading Axis one step forward to WS-I BP 1.0. :-)
>
> >
> > Note that R2717 says the opposite for rpc/literal.
> >
> > BTW, I don't have an easy way to track the code changes. Are
> > y'all creating tests for the bugs you close? That way the bug
> > will never be reintroduced.
> >
>
> Testing Java->WSDL (and even WSDL->Java) seems quite tough in terms of
> artifacts, not runtime workability. Probably we need a testing framework for
> a WSDL processor, particularly, walking with WS-I Profiles. How about
> inventing WSUnit (WebServicesUnit)? (Or already exists?) For example,
>
> Having Java classes
> ->
> Processing them to a WSDL
> ->
> Checking certain assertions to the generated WSDL
>
> and vice versa,
>
> Having a WSDL
> ->
> Processing it to Java classes
> ->
> Checking certain assertions to the generated classes
>
> Your comments and opinions are welcome all the time.
>
> Regards,
>
> Ias
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/