See inline.
Simon
ant elder wrote:
On 9/5/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 9/5/07, Luciano Resende <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende <http://people.apache.org/%7Elresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
