Re: Generated WSDL <> original WSDL
- Original Message - From: "Daleiden, Mike" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 11:14 AM Subject: RE: Generated WSDL <> original WSDL >Is the filename specified as an absolute path? Or is it relative to the >web app? Please provide an example. as of now, the CVS version takes a resource too; just provide the path to it. of course, we dont fixup the url in WSDL to point to the local implementation, axis just hands back the file as is.
Re: Generated WSDL <> original WSDL
Looks like you just give it a file and it is opened as a file, relative to wherever the system thinks the current directory is. I'll probably tap in some code to resolve against resources on the classpath if a file isnt found, as that would deem the better approach. - Original Message - From: "Daleiden, Mike" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 11:14 AM Subject: RE: Generated WSDL <> original WSDL Is the filename specified as an absolute path? Or is it relative to the web app? Please provide an example. -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Generated WSDL <> original WSDL - Original Message - From: "Tom Jordahl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 7:13 AM Subject: RE: Generated WSDL <> original WSDL > Please keep in mind that Axis isn't "changing" the WSDL, it is > generating the WSDL from the Java classes it has at hand. The original WSDL is *gone*. Unless you keep it around with the property. What is the way to specify the filename? is it or some file the way I've seen hinted The latter isnt in the schema (yet), and neither are in the (not yet existent) Axis configuration guide...
RE: Generated WSDL <> original WSDL
The latter. It is an element inside the service description. See the (ick!) source code: deployment.wsdd.WSDDService.java. -- Tom Jordahl Macromedia Server Development -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Generated WSDL <> original WSDL - Original Message - From: "Tom Jordahl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 7:13 AM Subject: RE: Generated WSDL <> original WSDL > Please keep in mind that Axis isn't "changing" the WSDL, it is generating the WSDL from the Java classes it has at hand. The original WSDL is *gone*. Unless you keep it around with the property. What is the way to specify the filename? is it or some file the way I've seen hinted The latter isnt in the schema (yet), and neither are in the (not yet existent) Axis configuration guide...
RE: Generated WSDL <> original WSDL
Is the filename specified as an absolute path? Or is it relative to the web app? Please provide an example. -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Generated WSDL <> original WSDL - Original Message - From: "Tom Jordahl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 7:13 AM Subject: RE: Generated WSDL <> original WSDL > Please keep in mind that Axis isn't "changing" the WSDL, it is > generating the WSDL from the Java classes it has at hand. The original WSDL is *gone*. Unless you keep it around with the property. What is the way to specify the filename? is it or some file the way I've seen hinted The latter isnt in the schema (yet), and neither are in the (not yet existent) Axis configuration guide...
Re: Generated WSDL <> original WSDL
- Original Message - From: "Tom Jordahl" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 7:13 AM Subject: RE: Generated WSDL <> original WSDL > Please keep in mind that Axis isn't "changing" the WSDL, it is generating the WSDL from the Java classes it has at hand. The original WSDL is *gone*. Unless you keep it around with the property. What is the way to specify the filename? is it or some file the way I've seen hinted The latter isnt in the schema (yet), and neither are in the (not yet existent) Axis configuration guide...
RE: Generated WSDL <> original WSDL
Just re-read this message.
Java2WSDL uses the package name to map to the namespace.
I believe you can change this mapping in the WSDD, but I don't have the syntax off the
top of my head. I know Java2WSDL has command line switches for this, but you need the
?WSDL invocation to do the mappings.
This might solve your problem in the short term.
The meta-data of the JavaBean should probably contain the namespace from the original
WSDL. This would be a reasonable bug/enhancement request.
--
Tom Jordahl
Macromedia Server Development
-Original Message-
From: Daleiden, Mike [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 14, 2002 4:26 PM
To: [EMAIL PROTECTED]
Subject: RE: Generated WSDL <> original WSDL
My problem is that the namespace of one of my schema types was radically
changed ("http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ";
became "http://inbound.soap.airiq.handler.device.commserver.rcapp.com";)
which makes it a completely different namespace than what it started out
as. For some reason, Axis used the full package name of the JavaBean
class that was generated by WSDL2Java as the namespace for the schema
type, instead of the original namespace. Also, it only did this for ONE
of the generated JavaBean classes (which just happens to be based on a
complex schema type that is nested within another complex schema type).
Tom -- I cannot use the static WSDL, as it is not functionally
equivalent to the generated WSDL. The web service implementation code
(running under Axis on my server) throws faults (illegal element(s) in
request) when it receives client requests based on the static WSDL.
What is causing Axis to generate the faulty WSDL?
-Original Message-
From: Wei Chen [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 14, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: RE: Generated WSDL <> original WSDL
Hi, Tom,
I am not sure I understand the functional equivalence.
If the client is generated based on the generated WSDL, it can not
always invoke the server based on the original WSDL.
One case I run into is the namespace changed. For example, if the
original namespace is urn://a/b/c, the Java package will be c.b.a, and
the generated WSDL will be http://a/b/c.
Another case I run into is the case issue. An XML type named "street"
will generate a Java class "Street". The generated WSDL will use
"Street" as the XML type.
It seems to me you can not get an equivalent WSDL back from the
round-trip (WSDL -> Java -> WSDL).
- Wei Chen
-Original Message-
From: Tom Jordahl [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 14, 2002 11:16 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Generated WSDL <> original WSDL
Axis will generate the WSDL from the Java classes. This is not
guaranteed to exactly match the WSDL those classes were generated from,
although they should be functionally equivalent.
You can specify the /path/to/file attribute for the
service in the server-config.wsdd if you want the WSDL to be static.
I took a look at the StreetAddress definitions, and the only difference
I saw was the nillable="true" attribute. This is because the Java
String objects can have a null value, so Java2WSDL specifies that in the
WSDL.
--
Tom Jordahl
Macromedia Server Development
-Original Message-
From: Daleiden, Mike [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 14, 2002 1:52 PM
To: [EMAIL PROTECTED]
Subject: Generated WSDL <> original WSDL
I hand-built a WSDL file to describe my web services, then used
WSDL2Java as follows to generate the stubs and server-side code:
java WSDL2Java -v -a -s --NStoPkg
http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ=com.aaares
ponse.rcapp.commserver.device.handler.airiq.soap.inbound webservice.wsdl
I then compiled the generated code and deployed it on my app server (BEA
WebLogic 6.1 SP1) and hit the URL to view the generated WSDL for my
service. The generated WSDL was very much different from the original
WSDL (particularly with respect to the schema definitions for
VehicleLocationInfo and StreetAddress). Is there something in my
original WSDL that is not quite correct that is causing the code to
generate the oddities in the generated WSDL?
This has been frustrating me for hours now, and I really don't
understand what's going on!
Here are the two WSDLs:
Original WSDL:
===
http://schemas.xmlsoap.org/wsdl/http/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:s="http://www.w3.org/2001/XMLSchema";
xmlns:s0="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/";
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/";
targetName
RE: Generated WSDL <> original WSDL
There are various situations where this round trip is either 1) not possible or 2) has bugs. 1) It might not be possible because in going from WSDL->Java, information is lost. In general we keep *most* of the important information in meta data, but important was defined as being required to get the "on-the-wire" XML correct. We may want to redefine this to include some WSDL round trip info too. 2) It might be a bug because Java2WSDL might not be looking at some meta data that *is* there. As far as your particular case, I agree that putting a Schema type in another name space is wrong. As to why it is wrong, I don't know. Code patches are always welcome. :-) Please keep in mind that Axis isn't "changing" the WSDL, it is generating the WSDL from the Java classes it has at hand. The original WSDL is *gone*. Unless you keep it around with the property. Again, it sure sounds like you have a bug, if you can create a small test case that shows the complexType in a different namespace problem and file a bugzilla report, that would be very helpful. -- Tom Jordahl Macromedia Server Development -Original Message- From: Daleiden, Mike [mailto:[EMAIL PROTECTED]] Sent: Friday, November 15, 2002 10:29 AM To: [EMAIL PROTECTED] Subject: RE: Generated WSDL <> original WSDL My concern with this is not that the generated WSDL be "identical", but rather "functionally equivalent". The whole idea behind WSDL is that it defines a service contract, so when I built the original WSDL and gave it to our client, it became a contract that both sides were to abide by. Unfortunately, after the round-trip engineering (WSDL->Java->WSDL), Axis changed the content of this contract, by moving a type definition from one schema namespace to another. My client implemented their code based on the original contract, and this code does not work with the altered WSDL contract that Axis generated (Axis throws faults because it is trying to reference different schema namespaces and elements). So, back to the original questions: why did Axis change the WSDL so dramatically? Is there anything I can do in the original WSDL or WSDL2Java that will alleviate the problems? -Original Message- From: Wei Chen [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 14, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: RE: Generated WSDL <> original WSDL Hi, Tom, I am not sure I understand the functional equivalence. If the client is generated based on the generated WSDL, it can not always invoke the server based on the original WSDL. One case I run into is the namespace changed. For example, if the original namespace is urn://a/b/c, the Java package will be c.b.a, and the generated WSDL will be http://a/b/c. Another case I run into is the case issue. An XML type named "street" will generate a Java class "Street". The generated WSDL will use "Street" as the XML type. It seems to me you can not get an equivalent WSDL back from the round-trip (WSDL -> Java -> WSDL). - Wei Chen -Original Message- From: Tom Jordahl [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 14, 2002 11:16 AM To: '[EMAIL PROTECTED]' Subject: RE: Generated WSDL <> original WSDL Axis will generate the WSDL from the Java classes. This is not guaranteed to exactly match the WSDL those classes were generated from, although they should be functionally equivalent. You can specify the /path/to/file attribute for the service in the server-config.wsdd if you want the WSDL to be static. I took a look at the StreetAddress definitions, and the only difference I saw was the nillable="true" attribute. This is because the Java String objects can have a null value, so Java2WSDL specifies that in the WSDL. -- Tom Jordahl Macromedia Server Development -Original Message- From: Daleiden, Mike [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 14, 2002 1:52 PM To: [EMAIL PROTECTED] Subject: Generated WSDL <> original WSDL I hand-built a WSDL file to describe my web services, then used WSDL2Java as follows to generate the stubs and server-side code: java WSDL2Java -v -a -s --NStoPkg http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ=com.aaares ponse.rcapp.commserver.device.handler.airiq.soap.inbound webservice.wsdl I then compiled the generated code and deployed it on my app server (BEA WebLogic 6.1 SP1) and hit the URL to view the generated WSDL for my service. The generated WSDL was very much different from the original WSDL (particularly with respect to the schema definitions for VehicleLocationInfo and StreetAddress). Is there something in my original WSDL that is not quite correct that is causing the code to generate the oddities in the generated WSDL? This has been frustrating me for hours now, and I really don't understand what's going on! Here are the two WSDL
RE: Generated WSDL <> original WSDL
My concern with this is not that the generated WSDL be "identical", but rather "functionally equivalent". The whole idea behind WSDL is that it defines a service contract, so when I built the original WSDL and gave it to our client, it became a contract that both sides were to abide by. Unfortunately, after the round-trip engineering (WSDL->Java->WSDL), Axis changed the content of this contract, by moving a type definition from one schema namespace to another. My client implemented their code based on the original contract, and this code does not work with the altered WSDL contract that Axis generated (Axis throws faults because it is trying to reference different schema namespaces and elements). So, back to the original questions: why did Axis change the WSDL so dramatically? Is there anything I can do in the original WSDL or WSDL2Java that will alleviate the problems? -Original Message- From: Wei Chen [mailto:wchen@;vitria.com] Sent: Thursday, November 14, 2002 2:34 PM To: [EMAIL PROTECTED] Subject: RE: Generated WSDL <> original WSDL Hi, Tom, I am not sure I understand the functional equivalence. If the client is generated based on the generated WSDL, it can not always invoke the server based on the original WSDL. One case I run into is the namespace changed. For example, if the original namespace is urn://a/b/c, the Java package will be c.b.a, and the generated WSDL will be http://a/b/c. Another case I run into is the case issue. An XML type named "street" will generate a Java class "Street". The generated WSDL will use "Street" as the XML type. It seems to me you can not get an equivalent WSDL back from the round-trip (WSDL -> Java -> WSDL). - Wei Chen -Original Message- From: Tom Jordahl [mailto:tomj@;macromedia.com] Sent: Thursday, November 14, 2002 11:16 AM To: '[EMAIL PROTECTED]' Subject: RE: Generated WSDL <> original WSDL Axis will generate the WSDL from the Java classes. This is not guaranteed to exactly match the WSDL those classes were generated from, although they should be functionally equivalent. You can specify the /path/to/file attribute for the service in the server-config.wsdd if you want the WSDL to be static. I took a look at the StreetAddress definitions, and the only difference I saw was the nillable="true" attribute. This is because the Java String objects can have a null value, so Java2WSDL specifies that in the WSDL. -- Tom Jordahl Macromedia Server Development -Original Message- From: Daleiden, Mike [mailto:mike.daleiden@;aaaresponse.com] Sent: Thursday, November 14, 2002 1:52 PM To: [EMAIL PROTECTED] Subject: Generated WSDL <> original WSDL I hand-built a WSDL file to describe my web services, then used WSDL2Java as follows to generate the stubs and server-side code: java WSDL2Java -v -a -s --NStoPkg http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ=com.aaares ponse.rcapp.commserver.device.handler.airiq.soap.inbound webservice.wsdl I then compiled the generated code and deployed it on my app server (BEA WebLogic 6.1 SP1) and hit the URL to view the generated WSDL for my service. The generated WSDL was very much different from the original WSDL (particularly with respect to the schema definitions for VehicleLocationInfo and StreetAddress). Is there something in my original WSDL that is not quite correct that is causing the code to generate the oddities in the generated WSDL? This has been frustrating me for hours now, and I really don't understand what's going on! Here are the two WSDLs: Original WSDL: === http://schemas.xmlsoap.org/wsdl/http/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:s="http://www.w3.org/2001/XMLSchema"; xmlns:s0="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; targetNamespace
RE: Generated WSDL <> original WSDL
My problem is that the namespace of one of my schema types was radically
changed ("http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ";
became "http://inbound.soap.airiq.handler.device.commserver.rcapp.com";)
which makes it a completely different namespace than what it started out
as. For some reason, Axis used the full package name of the JavaBean
class that was generated by WSDL2Java as the namespace for the schema
type, instead of the original namespace. Also, it only did this for ONE
of the generated JavaBean classes (which just happens to be based on a
complex schema type that is nested within another complex schema type).
Tom -- I cannot use the static WSDL, as it is not functionally
equivalent to the generated WSDL. The web service implementation code
(running under Axis on my server) throws faults (illegal element(s) in
request) when it receives client requests based on the static WSDL.
What is causing Axis to generate the faulty WSDL?
-Original Message-
From: Wei Chen [mailto:wchen@;vitria.com]
Sent: Thursday, November 14, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: RE: Generated WSDL <> original WSDL
Hi, Tom,
I am not sure I understand the functional equivalence.
If the client is generated based on the generated WSDL, it can not
always invoke the server based on the original WSDL.
One case I run into is the namespace changed. For example, if the
original namespace is urn://a/b/c, the Java package will be c.b.a, and
the generated WSDL will be http://a/b/c.
Another case I run into is the case issue. An XML type named "street"
will generate a Java class "Street". The generated WSDL will use
"Street" as the XML type.
It seems to me you can not get an equivalent WSDL back from the
round-trip (WSDL -> Java -> WSDL).
- Wei Chen
-Original Message-
From: Tom Jordahl [mailto:tomj@;macromedia.com]
Sent: Thursday, November 14, 2002 11:16 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Generated WSDL <> original WSDL
Axis will generate the WSDL from the Java classes. This is not
guaranteed to exactly match the WSDL those classes were generated from,
although they should be functionally equivalent.
You can specify the /path/to/file attribute for the
service in the server-config.wsdd if you want the WSDL to be static.
I took a look at the StreetAddress definitions, and the only difference
I saw was the nillable="true" attribute. This is because the Java
String objects can have a null value, so Java2WSDL specifies that in the
WSDL.
--
Tom Jordahl
Macromedia Server Development
-Original Message-
From: Daleiden, Mike [mailto:mike.daleiden@;aaaresponse.com]
Sent: Thursday, November 14, 2002 1:52 PM
To: [EMAIL PROTECTED]
Subject: Generated WSDL <> original WSDL
I hand-built a WSDL file to describe my web services, then used
WSDL2Java as follows to generate the stubs and server-side code:
java WSDL2Java -v -a -s --NStoPkg
http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ=com.aaares
ponse.rcapp.commserver.device.handler.airiq.soap.inbound webservice.wsdl
I then compiled the generated code and deployed it on my app server (BEA
WebLogic 6.1 SP1) and hit the URL to view the generated WSDL for my
service. The generated WSDL was very much different from the original
WSDL (particularly with respect to the schema definitions for
VehicleLocationInfo and StreetAddress). Is there something in my
original WSDL that is not quite correct that is causing the code to
generate the oddities in the generated WSDL?
This has been frustrating me for hours now, and I really don't
understand what's going on!
Here are the two WSDLs:
Original WSDL:
===
http://schemas.xmlsoap.org/wsdl/http/";
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:s="http://www.w3.org/2001/XMLSchema";
xmlns:s0="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ";
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/";
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/";
targetNamespace="
RE: Generated WSDL <> original WSDL
Hi, Tom, I am not sure I understand the functional equivalence. If the client is generated based on the generated WSDL, it can not always invoke the server based on the original WSDL. One case I run into is the namespace changed. For example, if the original namespace is urn://a/b/c, the Java package will be c.b.a, and the generated WSDL will be http://a/b/c. Another case I run into is the case issue. An XML type named "street" will generate a Java class "Street". The generated WSDL will use "Street" as the XML type. It seems to me you can not get an equivalent WSDL back from the round-trip (WSDL -> Java -> WSDL). - Wei Chen -Original Message- From: Tom Jordahl [mailto:tomj@;macromedia.com] Sent: Thursday, November 14, 2002 11:16 AM To: '[EMAIL PROTECTED]' Subject: RE: Generated WSDL <> original WSDL Axis will generate the WSDL from the Java classes. This is not guaranteed to exactly match the WSDL those classes were generated from, although they should be functionally equivalent. You can specify the /path/to/file attribute for the service in the server-config.wsdd if you want the WSDL to be static. I took a look at the StreetAddress definitions, and the only difference I saw was the nillable="true" attribute. This is because the Java String objects can have a null value, so Java2WSDL specifies that in the WSDL. -- Tom Jordahl Macromedia Server Development -Original Message- From: Daleiden, Mike [mailto:mike.daleiden@;aaaresponse.com] Sent: Thursday, November 14, 2002 1:52 PM To: [EMAIL PROTECTED] Subject: Generated WSDL <> original WSDL I hand-built a WSDL file to describe my web services, then used WSDL2Java as follows to generate the stubs and server-side code: java WSDL2Java -v -a -s --NStoPkg http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ=com.aaares ponse.rcapp.commserver.device.handler.airiq.soap.inbound webservice.wsdl I then compiled the generated code and deployed it on my app server (BEA WebLogic 6.1 SP1) and hit the URL to view the generated WSDL for my service. The generated WSDL was very much different from the original WSDL (particularly with respect to the schema definitions for VehicleLocationInfo and StreetAddress). Is there something in my original WSDL that is not quite correct that is causing the code to generate the oddities in the generated WSDL? This has been frustrating me for hours now, and I really don't understand what's going on! Here are the two WSDLs: Original WSDL: === http://schemas.xmlsoap.org/wsdl/http/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:s="http://www.w3.org/2001/XMLSchema"; xmlns:s0="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; targetNamespace="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns="http://schemas.xmlsoap.org/wsdl/";> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ";> http://schemas.xmlsoap.org/soap/http"; style="document" /> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ/SubmitA ctionResponse" style="document" /> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ/SubmitA lert" style="document" /> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; /> === Generated WSDL: === http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:apachesoap="http://xml.apache.org/xml-soap"; xmlns:impl="http://coq
Re: Generated WSDL <> original WSDL
Tom Jordahl wrote: > Axis will generate the WSDL from the Java classes. This is not guaranteed to >exactly match the WSDL those classes were generated from, although they should be >functionally equivalent. > > You can specify the /path/to/file attribute for the service in >the server-config.wsdd if you want the WSDL to be static. > > I took a look at the StreetAddress definitions, and the only difference I saw was >the nillable="true" attribute. This is because the Java String objects can have a >null value, so Java2WSDL specifies that in the WSDL. I filed a bug report where the java class has (I think) 6 overloaded methods, the on-the-fly generation of the wsdl had 7 methods, with two being functionally identical. An inexact match is one thing, but there are ways to get it to be completely off. I doubt the supplied wsdl for this thread is an example though.
RE: Generated WSDL <> original WSDL
Tom -
Thanks for the response. The issue that I have is with the fact that
Axis moved the StreetAddress type definition into a separate schema with
a separate namespace. The original WSDL specified that all of the types
were in the same namespace. The result is that the client code (which
is being developed by a third-party and not under my control) is
experiencing issues with using the generated WSDL. The client code is
.NET code, but here is the SOAP conversation between the .NET client and
my Axis server:
Client SOAP request:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ";>
AAA-1
{1D21927D-51D1-4547-A0BA-411D231F7E2B}
String
3.14159
3.14159
3.14159
3.14159
3.14159
3.14159
String
String
String
String
String
String
2002-11-14
12:12:11
String
2002-11-14
12:12:12
===
Axis response:
===
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
http://xml.apache.org/axis/";>ns1:Server.userException
org.xml.sax.SAXException: Invalid
element in
com.aaaresponse.rcapp.commserver.device.handler.airiq.soap.inbound.Vehic
leLocationInfo - Longitude
http://xml.apache.org/axis/";>org.xml.sax.SAXException:
Invalid element in
com.aaaresponse.rcapp.commserver.device.handler.airiq.soap.inbound.Vehic
leLocationInfo - Longitude
at
org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeseriali
zer.java:252)
at
org.apache.axis.encoding.DeserializationContextImpl.startElement(Deseria
lizationContextImpl.java:893)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:
200)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.j
ava:684)
at
org.apache.axis.message.RPCElement.deserialize(RPCElement.java:207)
at
org.apache.axis.message.RPCElement.getParams(RPCElement.java:265)
at
org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.ja
va:190)
at
org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:276
)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.j
ava:71)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:156)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:126)
at
org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:437)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:316)
at
org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:701)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.j
ava:335)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
java:265)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.
java:200)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServl
etContext.java:2456)
at
weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.
java:1985)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--Mike
-Original Message-
From: Tom Jordahl [mailto:tomj@;macromedia.com]
Sent: Thursday, November 14, 2002 2:16 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Generated WSDL <> original WSDL
Axis will generate the WSDL from the Java classes. This is not
guaranteed to exactly match the WSDL those classes were generated from,
althou
RE: Generated WSDL <> original WSDL
Axis will generate the WSDL from the Java classes. This is not guaranteed to exactly match the WSDL those classes were generated from, although they should be functionally equivalent. You can specify the /path/to/file attribute for the service in the server-config.wsdd if you want the WSDL to be static. I took a look at the StreetAddress definitions, and the only difference I saw was the nillable="true" attribute. This is because the Java String objects can have a null value, so Java2WSDL specifies that in the WSDL. -- Tom Jordahl Macromedia Server Development -Original Message- From: Daleiden, Mike [mailto:mike.daleiden@;aaaresponse.com] Sent: Thursday, November 14, 2002 1:52 PM To: [EMAIL PROTECTED] Subject: Generated WSDL <> original WSDL I hand-built a WSDL file to describe my web services, then used WSDL2Java as follows to generate the stubs and server-side code: java WSDL2Java -v -a -s --NStoPkg http://coqawl01-nat.aaaresponse.com:7001/rcapp/services/AirIQ=com.aaares ponse.rcapp.commserver.device.handler.airiq.soap.inbound webservice.wsdl I then compiled the generated code and deployed it on my app server (BEA WebLogic 6.1 SP1) and hit the URL to view the generated WSDL for my service. The generated WSDL was very much different from the original WSDL (particularly with respect to the schema definitions for VehicleLocationInfo and StreetAddress). Is there something in my original WSDL that is not quite correct that is causing the code to generate the oddities in the generated WSDL? This has been frustrating me for hours now, and I really don't understand what's going on! Here are the two WSDLs: Original WSDL: === http://schemas.xmlsoap.org/wsdl/http/"; xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:s="http://www.w3.org/2001/XMLSchema"; xmlns:s0="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"; xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"; targetNamespace="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns="http://schemas.xmlsoap.org/wsdl/";> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ";> http://schemas.xmlsoap.org/soap/http"; style="document" /> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ/SubmitA ctionResponse" style="document" /> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ/SubmitA lert" style="document" /> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; /> === Generated WSDL: === http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:apachesoap="http://xml.apache.org/xml-soap"; xmlns:impl="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns:intf="http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tns1="http://inbound.soap.airiq.handler.device.commserver.rcapp.aa aresponse.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";> http://coqawl01-nat.aaaresponse.com:7001/rcapp/AirIQ"; xmlns="http://www.w3.org/2001/XMLSchema";> http://schemas.xmlsoap.org/soap/encoding/"/>
