You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Dirk Wollscheid <wo...@us.ibm.com> on 2004/08/06 20:52:21 UTC
Problems with WS-Transaction WSDLs and WSDL2Ws
Hi, I'm playing with the WS-Transaction WSDLs and axis-c. I want to
generate client and server code for these WSDLs.
I've tried both the V1.2 and today's CVS version. There are some runtime
errors and also some compile errors.
I initially reported this in this bug
http://nagoya.apache.org/jira/browse/AXISCPP-96 . This was with V1.1 and
yesteray I updated the bug with the information using axis-c V1.2
I can provide the WSDLs and any other information that's necessary to
investigate and fix this.
Thanks, Dirk
Dirk Wollscheid
DB2 Webservices Development and other Database/Java/XML stuff
email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
"They say that time changes things, but you actually have to change them
yourself. " - A. W.
"You can hide what you know, but you can't hide what you don't know" -
Unknown
RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- Susantha Kumara <su...@opensource.lk> wrote:
>
> > -----Original Message-----
> > From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> > Sent: Monday, August 23, 2004 11:52 AM
> > To: Apache AXIS C Developers List
> > Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws
> >
> > Hi Dirk,
> > I tested your solution 3) to solve the namespace prefix problem
> and it
> > works, hence commited
> > that to cvs. Thank you for the solution.
> > However, your solutions 1) and 2) does not solve the problems. I
> think
> > this would require
> > definitions in include/axis/server/AxisUserAPI.h similar to
> xsd__NMTOKEN
> > and xsd__NMTOKEN_Array:
> > xsd__ID and xsd__ID_Array
> > xsd__NCName and xsd__NCName_Array
> >
> > For me this actually looks like supporting a full list of XSD
> types. I
>
> Yes have to enter the missing ones in to AxisUserAPI.h.
>
> > will look into the
> > details.
> >
> > BTW, the errors related to inclusion of non existing header files
> have
> > been solved. However
> > for wstx.wsdl you get "ReceivedType.h: No such file or directory"
> > This happens due to tool not being able to deal with
> > <xsd:complexType name="ReceivedType"> definition. This is a bug and
> need
>
> What is the wsdl you have this ReceivedType ?.
wstx.wsdl
Samisa...
>
> > to be fixed.
> > (this I suppose something to do with -nonwrapped part of the code)
> >
> > Thanks,
> > Samisa...
> >
> > --- Dirk Wollscheid <wo...@us.ibm.com> wrote:
> >
> > > I figured out where some of the errors during code generation come
> > from.
> > >
> > > 1) The "Error : an attribute is not basic type" errors come from the
> > > {http://www.w3.org/2001/XMLSchema}NCName and
> > > {http://www.w3.org/2001/XMLSchema}ID types being used in the
> > > ws-utility.xsd and the WS-Adressing WSDL. It seems like this can
> easily
> > > fixed by adding the two types to
> org.apache.axis.wsdl.wsdl2ws.CUtils.
> > e.g.
> > > with something like this (I'm not sure if this is the right
> mapping).
> > > qname2classmap.put(new
> > > QName(WrapperConstants.SCHEMA_NAMESPACE, "ID"), "xsd__string");
> > > qname2classmap.put(new
> > > QName(WrapperConstants.SCHEMA_NAMESPACE, "NCName"), "xsd__string");
> > >
> > > 2) The ServiceNameType comes from the WS-Adressing WSDL that I
> didn't
> > > include in the zip file. I guess WSDL4J gets it from here:
> > > http://schemas.xmlsoap.org/ws/2003/03/addressing/ That seems to be
> fixed
> > > with the change above too.
> > >
> > > 3) The problems with the namespace prefixes in the enumeration stem
> from
> > > CUtils.getRestrictionBaseAndValues. I modfied the code to this:
> > >
> > > // Process the enumeration elements
> underneath
> > the
> > > restriction node
> > > if (baseEType != null && restrictionNode !=
> > null)
> > > {
> > > Vector v = new Vector();
> > > NodeList enums =
> > > restrictionNode.getChildNodes();
> > > for (int i=0; i < enums.getLength();
> > i++)
> > > {
> > > QName enumKind =
> > > Utils.getNodeQName(enums.item(i));
> > > if (enumKind != null &&
> > >
> > > /*enumKind.getLocalPart().equals("enumeration") && lets put all not
> only
> > > enumerations */
> > > Constants.isSchemaXSD(enumKind.getNamespaceURI())) {
> > > Node
> enumNode =
> > > enums.item(i);
> > > String value
> =
> > > Utils.getAttribute(enumNode, "value");
> > > /*if (value
> !=
> > > null) {
> > > v.add(value);
> > > }*/
> > > // HACK
> wollsch
> > > if
> > (value.indexOf(
> > > ':')>0) {
> > > value=value.substring(value.indexOf(':')+1,value.length());
> > > }
> > > v.add(new
> > > QName(value, enumKind.getLocalPart()));
> > > }
> > > }
> > >
> > > // is this really an enumeration?
> > > /* if(v.isEmpty()) return null;
> There
> > can
> > > be restriction without any child nodes */
> > > // The first element in the vector
> is
> > the
> > > base type (an TypeEntry).
> > > v.add(0,baseEType);
> > > return v;
> > > }
> > >
> > > I also changed line 128 in
> org.apache.axis.wsdl.wsdl2ws.cpp.literal.
> > > ParmHeaderFileWriter::writeSimpleTypeWithEnumerations to this:
> > >
> > > writer.write("static const "+classname+" "+classname+"_"
> > > +value.getNamespaceURI()+" = \""+ value.getNamespaceURI()+"\";\n");
> > >
> > > That means the generated code looks like this (tContextFault.h)
> > >
> > > typedef xsd__QName tContextFault;
> > > static const tContextFault tContextFault_ContextEstablished =
> > > "ContextEstablished";
> > > static const tContextFault tContextFault_ContextUnknown =
> > > "ContextUnknown";
> > >
> > > Is this fix correct? or should the namepace encoded somewhere in
> there?
> > >
> > > Regards, Dirk
> > >
> > > Dirk Wollscheid
> > > DB2 Webservices Development and other Database/Java/XML stuff
> > > email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> > > "They say that time changes things, but you actually have to change
> them
> > > yourself. " - A. W.
> > > "You can hide what you know, but you can't hide what you don't know"
> -
> > > Unknown
> > > Please respond to "Apache AXIS C Developers List"
> > > <ax...@ws.apache.org>
> > > To: Apache AXIS C Developers List <ax...@ws.apache.org>
> > > cc:
> > > Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws
> > >
> > >
> > >
> > > I tried with latest Axis C++ cvs checkout today.
> > > The problem that Amila mentioned is no more there.
> > > However, all the other problems are there.
> > >
> > > 1. During generation there is an exception complaining about "Error
> : an
> > > attribute is not basic
> > > type"
> > > Further investigation revealed that this happens while generating
> > > 'ServiceNameType' related
> > > source files. However non of the xsd or wsdl files used has anything
> > > related to 'ServiceNameType'.
> > >
> > > 2. There are compilation erros in compiling the genrated code.
> > > 2.1 'ActivationCoordinatorPortType.h:14:29: ServiceNameType.h: No
> such
> > > file or directory'
> > > This is related to error in 1. The file 'ServiceNameType.h' is not
> > > generated but still the
> > > other files referance this.
> > >
> > > 2.2 'tContextFault.h:10: syntax error before `:' token'
> > > This is related to the piece of code generated:
> > > typedef xsd__QName tContextFault;
> > > static const tContextFault tContextFault_wsu:ContextEstablished =
> > > wsu:ContextEstablished;
> > > static const tContextFault tContextFault_wsu:ContextUnknown =
> > > wsu:ContextUnknown;
> > > static const tContextFault tContextFault_wsu:ContextNotSupported =
> > > wsu:ContextNotSupported;
> > > static const tContextFault tContextFault_wsu:ContextRefused =
>
=== message truncated ===
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Susantha Kumara <su...@opensource.lk>.
> -----Original Message-----
> From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> Sent: Monday, August 23, 2004 11:52 AM
> To: Apache AXIS C Developers List
> Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws
>
> Hi Dirk,
> I tested your solution 3) to solve the namespace prefix problem
and it
> works, hence commited
> that to cvs. Thank you for the solution.
> However, your solutions 1) and 2) does not solve the problems. I
think
> this would require
> definitions in include/axis/server/AxisUserAPI.h similar to
xsd__NMTOKEN
> and xsd__NMTOKEN_Array:
> xsd__ID and xsd__ID_Array
> xsd__NCName and xsd__NCName_Array
>
> For me this actually looks like supporting a full list of XSD
types. I
Yes have to enter the missing ones in to AxisUserAPI.h.
> will look into the
> details.
>
> BTW, the errors related to inclusion of non existing header files
have
> been solved. However
> for wstx.wsdl you get "ReceivedType.h: No such file or directory"
> This happens due to tool not being able to deal with
> <xsd:complexType name="ReceivedType"> definition. This is a bug and
need
What is the wsdl you have this ReceivedType ?.
> to be fixed.
> (this I suppose something to do with -nonwrapped part of the code)
>
> Thanks,
> Samisa...
>
> --- Dirk Wollscheid <wo...@us.ibm.com> wrote:
>
> > I figured out where some of the errors during code generation come
> from.
> >
> > 1) The "Error : an attribute is not basic type" errors come from the
> > {http://www.w3.org/2001/XMLSchema}NCName and
> > {http://www.w3.org/2001/XMLSchema}ID types being used in the
> > ws-utility.xsd and the WS-Adressing WSDL. It seems like this can
easily
> > fixed by adding the two types to
org.apache.axis.wsdl.wsdl2ws.CUtils.
> e.g.
> > with something like this (I'm not sure if this is the right
mapping).
> > qname2classmap.put(new
> > QName(WrapperConstants.SCHEMA_NAMESPACE, "ID"), "xsd__string");
> > qname2classmap.put(new
> > QName(WrapperConstants.SCHEMA_NAMESPACE, "NCName"), "xsd__string");
> >
> > 2) The ServiceNameType comes from the WS-Adressing WSDL that I
didn't
> > include in the zip file. I guess WSDL4J gets it from here:
> > http://schemas.xmlsoap.org/ws/2003/03/addressing/ That seems to be
fixed
> > with the change above too.
> >
> > 3) The problems with the namespace prefixes in the enumeration stem
from
> > CUtils.getRestrictionBaseAndValues. I modfied the code to this:
> >
> > // Process the enumeration elements
underneath
> the
> > restriction node
> > if (baseEType != null && restrictionNode !=
> null)
> > {
> > Vector v = new Vector();
> > NodeList enums =
> > restrictionNode.getChildNodes();
> > for (int i=0; i < enums.getLength();
> i++)
> > {
> > QName enumKind =
> > Utils.getNodeQName(enums.item(i));
> > if (enumKind != null &&
> >
> > /*enumKind.getLocalPart().equals("enumeration") && lets put all not
only
> > enumerations */
> > Constants.isSchemaXSD(enumKind.getNamespaceURI())) {
> > Node
enumNode =
> > enums.item(i);
> > String value
=
> > Utils.getAttribute(enumNode, "value");
> > /*if (value
!=
> > null) {
> > v.add(value);
> > }*/
> > // HACK
wollsch
> > if
> (value.indexOf(
> > ':')>0) {
> > value=value.substring(value.indexOf(':')+1,value.length());
> > }
> > v.add(new
> > QName(value, enumKind.getLocalPart()));
> > }
> > }
> >
> > // is this really an enumeration?
> > /* if(v.isEmpty()) return null;
There
> can
> > be restriction without any child nodes */
> > // The first element in the vector
is
> the
> > base type (an TypeEntry).
> > v.add(0,baseEType);
> > return v;
> > }
> >
> > I also changed line 128 in
org.apache.axis.wsdl.wsdl2ws.cpp.literal.
> > ParmHeaderFileWriter::writeSimpleTypeWithEnumerations to this:
> >
> > writer.write("static const "+classname+" "+classname+"_"
> > +value.getNamespaceURI()+" = \""+ value.getNamespaceURI()+"\";\n");
> >
> > That means the generated code looks like this (tContextFault.h)
> >
> > typedef xsd__QName tContextFault;
> > static const tContextFault tContextFault_ContextEstablished =
> > "ContextEstablished";
> > static const tContextFault tContextFault_ContextUnknown =
> > "ContextUnknown";
> >
> > Is this fix correct? or should the namepace encoded somewhere in
there?
> >
> > Regards, Dirk
> >
> > Dirk Wollscheid
> > DB2 Webservices Development and other Database/Java/XML stuff
> > email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> > "They say that time changes things, but you actually have to change
them
> > yourself. " - A. W.
> > "You can hide what you know, but you can't hide what you don't know"
-
> > Unknown
> > Please respond to "Apache AXIS C Developers List"
> > <ax...@ws.apache.org>
> > To: Apache AXIS C Developers List <ax...@ws.apache.org>
> > cc:
> > Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws
> >
> >
> >
> > I tried with latest Axis C++ cvs checkout today.
> > The problem that Amila mentioned is no more there.
> > However, all the other problems are there.
> >
> > 1. During generation there is an exception complaining about "Error
: an
> > attribute is not basic
> > type"
> > Further investigation revealed that this happens while generating
> > 'ServiceNameType' related
> > source files. However non of the xsd or wsdl files used has anything
> > related to 'ServiceNameType'.
> >
> > 2. There are compilation erros in compiling the genrated code.
> > 2.1 'ActivationCoordinatorPortType.h:14:29: ServiceNameType.h: No
such
> > file or directory'
> > This is related to error in 1. The file 'ServiceNameType.h' is not
> > generated but still the
> > other files referance this.
> >
> > 2.2 'tContextFault.h:10: syntax error before `:' token'
> > This is related to the piece of code generated:
> > typedef xsd__QName tContextFault;
> > static const tContextFault tContextFault_wsu:ContextEstablished =
> > wsu:ContextEstablished;
> > static const tContextFault tContextFault_wsu:ContextUnknown =
> > wsu:ContextUnknown;
> > static const tContextFault tContextFault_wsu:ContextNotSupported =
> > wsu:ContextNotSupported;
> > static const tContextFault tContextFault_wsu:ContextRefused =
> > wsu:ContextRefused;
> > static const tContextFault tContextFault_wsu:ContextExpired =
> > wsu:ContextExpired;
> >
> > which relates to xsd file content:
> > <xsd:simpleType name="tContextFault">
> > <xsd:annotation>
> > <xsd:documentation>
> > This type defines the fault code values for context-related faults.
> > </xsd:documentation>
> > </xsd:annotation>
> > <xsd:restriction base="xsd:QName">
> > <xsd:enumeration value="wsu:ContextEstablished"/>
> > <xsd:enumeration value="wsu:ContextUnknown"/>
> > <xsd:enumeration value="wsu:ContextNotSupported"/>
> > <xsd:enumeration value="wsu:ContextRefused"/>
> > <xsd:enumeration value="wsu:ContextExpired"/>
> > </xsd:restriction>
> > </xsd:simpleType>
> >
> > This is a bug related to the handling of restrictions. It uses
prefix
> > (i.e. wsu as it is from xsd
> > file). I got the feeling that the valuse assignment for the enum
values
> > should have been string
> > (char*) and that is not properly genarated by the tool.
> >
> > The bugs that I mentioned earlier (handling ANON_TOKEN) has been
> partially
> > fixed. But the problems
> > that appear for these wsdls are new bugs, hence will take some time
> > attending.
> >
> > I will try and attend them in case I get some time.
> >
> > Thanks,
> > Samisa...
> >
> >
> >
> > --- Amila Rathnayake <am...@opensource.lk> wrote:
> >
> > > Hi Dirk,
> > >
> > > According to your previous mail and the bug reported in Jira
> > > (http://nagoya.apache.org/jira/browse/AXISCPP-96), it has
mentioned
> that
> > > the problem seems to be in the line
> > >
> > > this.typeMap.removeType(qname);
> > >
> > > in the method of ;
> > >
> > > WSDL2Ws::getServiceInfo
> > >
> > > and also that you are using Axis C++ 1.1.1
> > >
> > > Yes, you are correct and there is a problem in that line in Axis
C++
> > > 1.1.1.
> > >
> > > When we use a wsdl in wrapped style, then there may be places
where it
> > > has defined non-named complex types but actual definition of that
type
> > > is also there in side of that complex type and it is actually a
simple
> > > type. So in this case we don't need to generate separate type for
that
> > > complex type and have to remove that from the TypeMap. Therefore
to
> > > cater this scenario it has inserted that line in the earlier
versions
> of
> > > Axis. Here is an example for that case;
> > >
> > > <types>
> > > <xsd:schema targetNamespace="http://www.sample.org/" >
> > > <xsd:element name="countWords">
> > > <xsd:complexType>
> > > <xsd:sequence>
> > > <xsd:element name="words" type="xsd:string" />
> > > </xsd:sequence>
> > > </xsd:complexType>
> > > </xsd:element>
> > > </xsd:schema>
> >
> === message truncated ===
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail
RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Dirk,
I tested your solution 3) to solve the namespace prefix problem and it works, hence commited
that to cvs. Thank you for the solution.
However, your solutions 1) and 2) does not solve the problems. I think this would require
definitions in include/axis/server/AxisUserAPI.h similar to xsd__NMTOKEN and xsd__NMTOKEN_Array:
xsd__ID and xsd__ID_Array
xsd__NCName and xsd__NCName_Array
For me this actually looks like supporting a full list of XSD types. I will look into the
details.
BTW, the errors related to inclusion of non existing header files have been solved. However
for wstx.wsdl you get "ReceivedType.h: No such file or directory"
This happens due to tool not being able to deal with
<xsd:complexType name="ReceivedType"> definition. This is a bug and need to be fixed.
(this I suppose something to do with -nonwrapped part of the code)
Thanks,
Samisa...
--- Dirk Wollscheid <wo...@us.ibm.com> wrote:
> I figured out where some of the errors during code generation come from.
>
> 1) The "Error : an attribute is not basic type" errors come from the
> {http://www.w3.org/2001/XMLSchema}NCName and
> {http://www.w3.org/2001/XMLSchema}ID types being used in the
> ws-utility.xsd and the WS-Adressing WSDL. It seems like this can easily
> fixed by adding the two types to org.apache.axis.wsdl.wsdl2ws.CUtils. e.g.
> with something like this (I'm not sure if this is the right mapping).
> qname2classmap.put(new
> QName(WrapperConstants.SCHEMA_NAMESPACE, "ID"), "xsd__string");
> qname2classmap.put(new
> QName(WrapperConstants.SCHEMA_NAMESPACE, "NCName"), "xsd__string");
>
> 2) The ServiceNameType comes from the WS-Adressing WSDL that I didn't
> include in the zip file. I guess WSDL4J gets it from here:
> http://schemas.xmlsoap.org/ws/2003/03/addressing/ That seems to be fixed
> with the change above too.
>
> 3) The problems with the namespace prefixes in the enumeration stem from
> CUtils.getRestrictionBaseAndValues. I modfied the code to this:
>
> // Process the enumeration elements underneath the
> restriction node
> if (baseEType != null && restrictionNode != null)
> {
> Vector v = new Vector();
> NodeList enums =
> restrictionNode.getChildNodes();
> for (int i=0; i < enums.getLength(); i++)
> {
> QName enumKind =
> Utils.getNodeQName(enums.item(i));
> if (enumKind != null &&
>
> /*enumKind.getLocalPart().equals("enumeration") && lets put all not only
> enumerations */
> Constants.isSchemaXSD(enumKind.getNamespaceURI())) {
> Node enumNode =
> enums.item(i);
> String value =
> Utils.getAttribute(enumNode, "value");
> /*if (value !=
> null) {
> v.add(value);
> }*/
> // HACK wollsch
> if (value.indexOf(
> ':')>0) {
> value=value.substring(value.indexOf(':')+1,value.length());
> }
> v.add(new
> QName(value, enumKind.getLocalPart()));
> }
> }
>
> // is this really an enumeration?
> /* if(v.isEmpty()) return null; There can
> be restriction without any child nodes */
> // The first element in the vector is the
> base type (an TypeEntry).
> v.add(0,baseEType);
> return v;
> }
>
> I also changed line 128 in org.apache.axis.wsdl.wsdl2ws.cpp.literal.
> ParmHeaderFileWriter::writeSimpleTypeWithEnumerations to this:
>
> writer.write("static const "+classname+" "+classname+"_"
> +value.getNamespaceURI()+" = \""+ value.getNamespaceURI()+"\";\n");
>
> That means the generated code looks like this (tContextFault.h)
>
> typedef xsd__QName tContextFault;
> static const tContextFault tContextFault_ContextEstablished =
> "ContextEstablished";
> static const tContextFault tContextFault_ContextUnknown =
> "ContextUnknown";
>
> Is this fix correct? or should the namepace encoded somewhere in there?
>
> Regards, Dirk
>
> Dirk Wollscheid
> DB2 Webservices Development and other Database/Java/XML stuff
> email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> "They say that time changes things, but you actually have to change them
> yourself. " - A. W.
> "You can hide what you know, but you can't hide what you don't know" -
> Unknown
> Please respond to "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> To: Apache AXIS C Developers List <ax...@ws.apache.org>
> cc:
> Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws
>
>
>
> I tried with latest Axis C++ cvs checkout today.
> The problem that Amila mentioned is no more there.
> However, all the other problems are there.
>
> 1. During generation there is an exception complaining about "Error : an
> attribute is not basic
> type"
> Further investigation revealed that this happens while generating
> 'ServiceNameType' related
> source files. However non of the xsd or wsdl files used has anything
> related to 'ServiceNameType'.
>
> 2. There are compilation erros in compiling the genrated code.
> 2.1 'ActivationCoordinatorPortType.h:14:29: ServiceNameType.h: No such
> file or directory'
> This is related to error in 1. The file 'ServiceNameType.h' is not
> generated but still the
> other files referance this.
>
> 2.2 'tContextFault.h:10: syntax error before `:' token'
> This is related to the piece of code generated:
> typedef xsd__QName tContextFault;
> static const tContextFault tContextFault_wsu:ContextEstablished =
> wsu:ContextEstablished;
> static const tContextFault tContextFault_wsu:ContextUnknown =
> wsu:ContextUnknown;
> static const tContextFault tContextFault_wsu:ContextNotSupported =
> wsu:ContextNotSupported;
> static const tContextFault tContextFault_wsu:ContextRefused =
> wsu:ContextRefused;
> static const tContextFault tContextFault_wsu:ContextExpired =
> wsu:ContextExpired;
>
> which relates to xsd file content:
> <xsd:simpleType name="tContextFault">
> <xsd:annotation>
> <xsd:documentation>
> This type defines the fault code values for context-related faults.
> </xsd:documentation>
> </xsd:annotation>
> <xsd:restriction base="xsd:QName">
> <xsd:enumeration value="wsu:ContextEstablished"/>
> <xsd:enumeration value="wsu:ContextUnknown"/>
> <xsd:enumeration value="wsu:ContextNotSupported"/>
> <xsd:enumeration value="wsu:ContextRefused"/>
> <xsd:enumeration value="wsu:ContextExpired"/>
> </xsd:restriction>
> </xsd:simpleType>
>
> This is a bug related to the handling of restrictions. It uses prefix
> (i.e. wsu as it is from xsd
> file). I got the feeling that the valuse assignment for the enum values
> should have been string
> (char*) and that is not properly genarated by the tool.
>
> The bugs that I mentioned earlier (handling ANON_TOKEN) has been partially
> fixed. But the problems
> that appear for these wsdls are new bugs, hence will take some time
> attending.
>
> I will try and attend them in case I get some time.
>
> Thanks,
> Samisa...
>
>
>
> --- Amila Rathnayake <am...@opensource.lk> wrote:
>
> > Hi Dirk,
> >
> > According to your previous mail and the bug reported in Jira
> > (http://nagoya.apache.org/jira/browse/AXISCPP-96), it has mentioned that
> > the problem seems to be in the line
> >
> > this.typeMap.removeType(qname);
> >
> > in the method of ;
> >
> > WSDL2Ws::getServiceInfo
> >
> > and also that you are using Axis C++ 1.1.1
> >
> > Yes, you are correct and there is a problem in that line in Axis C++
> > 1.1.1.
> >
> > When we use a wsdl in wrapped style, then there may be places where it
> > has defined non-named complex types but actual definition of that type
> > is also there in side of that complex type and it is actually a simple
> > type. So in this case we don't need to generate separate type for that
> > complex type and have to remove that from the TypeMap. Therefore to
> > cater this scenario it has inserted that line in the earlier versions of
> > Axis. Here is an example for that case;
> >
> > <types>
> > <xsd:schema targetNamespace="http://www.sample.org/" >
> > <xsd:element name="countWords">
> > <xsd:complexType>
> > <xsd:sequence>
> > <xsd:element name="words" type="xsd:string" />
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:element>
> > </xsd:schema>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Dirk Wollscheid <wo...@us.ibm.com>.
I figured out where some of the errors during code generation come from.
1) The "Error : an attribute is not basic type" errors come from the
{http://www.w3.org/2001/XMLSchema}NCName and
{http://www.w3.org/2001/XMLSchema}ID types being used in the
ws-utility.xsd and the WS-Adressing WSDL. It seems like this can easily
fixed by adding the two types to org.apache.axis.wsdl.wsdl2ws.CUtils. e.g.
with something like this (I'm not sure if this is the right mapping).
qname2classmap.put(new
QName(WrapperConstants.SCHEMA_NAMESPACE, "ID"), "xsd__string");
qname2classmap.put(new
QName(WrapperConstants.SCHEMA_NAMESPACE, "NCName"), "xsd__string");
2) The ServiceNameType comes from the WS-Adressing WSDL that I didn't
include in the zip file. I guess WSDL4J gets it from here:
http://schemas.xmlsoap.org/ws/2003/03/addressing/ That seems to be fixed
with the change above too.
3) The problems with the namespace prefixes in the enumeration stem from
CUtils.getRestrictionBaseAndValues. I modfied the code to this:
// Process the enumeration elements underneath the
restriction node
if (baseEType != null && restrictionNode != null)
{
Vector v = new Vector();
NodeList enums =
restrictionNode.getChildNodes();
for (int i=0; i < enums.getLength(); i++)
{
QName enumKind =
Utils.getNodeQName(enums.item(i));
if (enumKind != null &&
/*enumKind.getLocalPart().equals("enumeration") && lets put all not only
enumerations */
Constants.isSchemaXSD(enumKind.getNamespaceURI())) {
Node enumNode =
enums.item(i);
String value =
Utils.getAttribute(enumNode, "value");
/*if (value !=
null) {
v.add(value);
}*/
// HACK wollsch
if (value.indexOf(
':')>0) {
value=value.substring(value.indexOf(':')+1,value.length());
}
v.add(new
QName(value, enumKind.getLocalPart()));
}
}
// is this really an enumeration?
/* if(v.isEmpty()) return null; There can
be restriction without any child nodes */
// The first element in the vector is the
base type (an TypeEntry).
v.add(0,baseEType);
return v;
}
I also changed line 128 in org.apache.axis.wsdl.wsdl2ws.cpp.literal.
ParmHeaderFileWriter::writeSimpleTypeWithEnumerations to this:
writer.write("static const "+classname+" "+classname+"_"
+value.getNamespaceURI()+" = \""+ value.getNamespaceURI()+"\";\n");
That means the generated code looks like this (tContextFault.h)
typedef xsd__QName tContextFault;
static const tContextFault tContextFault_ContextEstablished =
"ContextEstablished";
static const tContextFault tContextFault_ContextUnknown =
"ContextUnknown";
Is this fix correct? or should the namepace encoded somewhere in there?
Regards, Dirk
Dirk Wollscheid
DB2 Webservices Development and other Database/Java/XML stuff
email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
"They say that time changes things, but you actually have to change them
yourself. " - A. W.
"You can hide what you know, but you can't hide what you don't know" -
Unknown
Please respond to "Apache AXIS C Developers List"
<ax...@ws.apache.org>
To: Apache AXIS C Developers List <ax...@ws.apache.org>
cc:
Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws
I tried with latest Axis C++ cvs checkout today.
The problem that Amila mentioned is no more there.
However, all the other problems are there.
1. During generation there is an exception complaining about "Error : an
attribute is not basic
type"
Further investigation revealed that this happens while generating
'ServiceNameType' related
source files. However non of the xsd or wsdl files used has anything
related to 'ServiceNameType'.
2. There are compilation erros in compiling the genrated code.
2.1 'ActivationCoordinatorPortType.h:14:29: ServiceNameType.h: No such
file or directory'
This is related to error in 1. The file 'ServiceNameType.h' is not
generated but still the
other files referance this.
2.2 'tContextFault.h:10: syntax error before `:' token'
This is related to the piece of code generated:
typedef xsd__QName tContextFault;
static const tContextFault tContextFault_wsu:ContextEstablished =
wsu:ContextEstablished;
static const tContextFault tContextFault_wsu:ContextUnknown =
wsu:ContextUnknown;
static const tContextFault tContextFault_wsu:ContextNotSupported =
wsu:ContextNotSupported;
static const tContextFault tContextFault_wsu:ContextRefused =
wsu:ContextRefused;
static const tContextFault tContextFault_wsu:ContextExpired =
wsu:ContextExpired;
which relates to xsd file content:
<xsd:simpleType name="tContextFault">
<xsd:annotation>
<xsd:documentation>
This type defines the fault code values for context-related faults.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:QName">
<xsd:enumeration value="wsu:ContextEstablished"/>
<xsd:enumeration value="wsu:ContextUnknown"/>
<xsd:enumeration value="wsu:ContextNotSupported"/>
<xsd:enumeration value="wsu:ContextRefused"/>
<xsd:enumeration value="wsu:ContextExpired"/>
</xsd:restriction>
</xsd:simpleType>
This is a bug related to the handling of restrictions. It uses prefix
(i.e. wsu as it is from xsd
file). I got the feeling that the valuse assignment for the enum values
should have been string
(char*) and that is not properly genarated by the tool.
The bugs that I mentioned earlier (handling ANON_TOKEN) has been partially
fixed. But the problems
that appear for these wsdls are new bugs, hence will take some time
attending.
I will try and attend them in case I get some time.
Thanks,
Samisa...
--- Amila Rathnayake <am...@opensource.lk> wrote:
> Hi Dirk,
>
> According to your previous mail and the bug reported in Jira
> (http://nagoya.apache.org/jira/browse/AXISCPP-96), it has mentioned that
> the problem seems to be in the line
>
> this.typeMap.removeType(qname);
>
> in the method of ;
>
> WSDL2Ws::getServiceInfo
>
> and also that you are using Axis C++ 1.1.1
>
> Yes, you are correct and there is a problem in that line in Axis C++
> 1.1.1.
>
> When we use a wsdl in wrapped style, then there may be places where it
> has defined non-named complex types but actual definition of that type
> is also there in side of that complex type and it is actually a simple
> type. So in this case we don't need to generate separate type for that
> complex type and have to remove that from the TypeMap. Therefore to
> cater this scenario it has inserted that line in the earlier versions of
> Axis. Here is an example for that case;
>
> <types>
> <xsd:schema targetNamespace="http://www.sample.org/" >
> <xsd:element name="countWords">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="words" type="xsd:string" />
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
> </types>
>
> But there are some wsdl's that has given a name for that inner complex
> type and will refer that complex type from other places in that wsdl by
> its name. Then if we remove the type created for that complex type from
> the TypeMap then it will cause other problems. So that removing of that
> complex type from the type map is not a good idea. So, that line has
> been commented out in the releases after 1.1.1 and it has done the
> refinement in Type::setTypeNameForElementName().
>
> You should not get this problem, if you use Axis C++ 1.2 Alpha or later.
>
> Thanks,
> Amila.
>
>
>
> -----Original Message-----
> From: Dirk Wollscheid [mailto:wollsch@us.ibm.com]
> Sent: Monday, August 09, 2004 10:33 PM
> To: Apache AXIS C Developers List
> Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
>
>
> Samisa,
>
> I attached a zip file with the WSDLs to the bug (AXISCPP-96 ) in JIRA.
>
> wstx-soap_lit_coord.wsdl is the binding that I created myself. The other
> files are standard, except I modified them for better WS-I compliance
> (the standards team is picking up those changes).
>
>
> The original standards files can be accessed with these URLs (Note:
> There's no binding defined - only port types)
> http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.wsdl
> http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.xsd
> http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.wsdl
> http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.xsd
>
> Thanks, Dirk
>
> Dirk Wollscheid
> DB2 Webservices Development and other Database/Java/XML stuff
> email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> "They say that time changes things, but you actually have to change them
> yourself. " - A. W.
> "You can hide what you know, but you can't hide what you don't know" -
> Unknown
> Please respond to "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> To: Apache AXIS C Developers List <ax...@ws.apache.org>
> cc:
> Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
>
>
>
> Hi Dirk,
> Axis C++ team is currently working on the tool to implement some new
> features.
>
> The compilation problem is a known bug. This comes due to the way
> 'ANON_TOKEN' constant,
> defined in SymbolTable class of Axis Java, is handled from Axis C++
> WSDL2Ws java tool. The team is
> aware of the problem and this will hopefully be solved soon.
>
> The generation exceptions could well be due to the fact that some of the
> WSDL features used in
> the WSDL file that you use not being supported by the Axis C++ WSDL2Ws
> implementation as yet.
>
> Please send the URL of the WSDL file, so that I could have a look on
> what is going wrong.
> Thanks,
> Samisa...
>
> --- Dirk Wollscheid <wo...@us.ibm.com> wrote:
>
> > Hi, I'm playing with the WS-Transaction WSDLs and axis-c. I want to
> > generate client and server code for these WSDLs.
> >
> > I've tried both the V1.2 and today's CVS version. There are some
> runtime
> > errors and also some compile errors.
> >
> > I initially reported this in this bug
> > http://nagoya.apache.org/jira/browse/AXISCPP-96 . This was with V1.1
> and
> > yesteray I updated the bug with the information using axis-c V1.2
> >
> > I can provide the WSDLs and any other information that's necessary to
> > investigate and fix this.
> >
> > Thanks, Dirk
> >
> > Dirk Wollscheid
> > DB2 Webservices Development and other Database/Java/XML stuff
> > email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> > "They say that time changes things, but you actually have to change
> them
> > yourself. " - A. W.
> > "You can hide what you know, but you can't hide what you don't know" -
> > Unknown
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
I tried with latest Axis C++ cvs checkout today.
The problem that Amila mentioned is no more there.
However, all the other problems are there.
1. During generation there is an exception complaining about "Error : an attribute is not basic
type"
Further investigation revealed that this happens while generating 'ServiceNameType' related
source files. However non of the xsd or wsdl files used has anything related to 'ServiceNameType'.
2. There are compilation erros in compiling the genrated code.
2.1 'ActivationCoordinatorPortType.h:14:29: ServiceNameType.h: No such file or directory'
This is related to error in 1. The file 'ServiceNameType.h' is not generated but still the
other files referance this.
2.2 'tContextFault.h:10: syntax error before `:' token'
This is related to the piece of code generated:
typedef xsd__QName tContextFault;
static const tContextFault tContextFault_wsu:ContextEstablished = wsu:ContextEstablished;
static const tContextFault tContextFault_wsu:ContextUnknown = wsu:ContextUnknown;
static const tContextFault tContextFault_wsu:ContextNotSupported = wsu:ContextNotSupported;
static const tContextFault tContextFault_wsu:ContextRefused = wsu:ContextRefused;
static const tContextFault tContextFault_wsu:ContextExpired = wsu:ContextExpired;
which relates to xsd file content:
<xsd:simpleType name="tContextFault">
<xsd:annotation>
<xsd:documentation>
This type defines the fault code values for context-related faults.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:QName">
<xsd:enumeration value="wsu:ContextEstablished"/>
<xsd:enumeration value="wsu:ContextUnknown"/>
<xsd:enumeration value="wsu:ContextNotSupported"/>
<xsd:enumeration value="wsu:ContextRefused"/>
<xsd:enumeration value="wsu:ContextExpired"/>
</xsd:restriction>
</xsd:simpleType>
This is a bug related to the handling of restrictions. It uses prefix (i.e. wsu as it is from xsd
file). I got the feeling that the valuse assignment for the enum values should have been string
(char*) and that is not properly genarated by the tool.
The bugs that I mentioned earlier (handling ANON_TOKEN) has been partially fixed. But the problems
that appear for these wsdls are new bugs, hence will take some time attending.
I will try and attend them in case I get some time.
Thanks,
Samisa...
--- Amila Rathnayake <am...@opensource.lk> wrote:
> Hi Dirk,
>
> According to your previous mail and the bug reported in Jira
> (http://nagoya.apache.org/jira/browse/AXISCPP-96), it has mentioned that
> the problem seems to be in the line
>
> this.typeMap.removeType(qname);
>
> in the method of ;
>
> WSDL2Ws::getServiceInfo
>
> and also that you are using Axis C++ 1.1.1
>
> Yes, you are correct and there is a problem in that line in Axis C++
> 1.1.1.
>
> When we use a wsdl in wrapped style, then there may be places where it
> has defined non-named complex types but actual definition of that type
> is also there in side of that complex type and it is actually a simple
> type. So in this case we don't need to generate separate type for that
> complex type and have to remove that from the TypeMap. Therefore to
> cater this scenario it has inserted that line in the earlier versions of
> Axis. Here is an example for that case;
>
> <types>
> <xsd:schema targetNamespace="http://www.sample.org/" >
> <xsd:element name="countWords">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="words" type="xsd:string" />
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
> </types>
>
> But there are some wsdl's that has given a name for that inner complex
> type and will refer that complex type from other places in that wsdl by
> its name. Then if we remove the type created for that complex type from
> the TypeMap then it will cause other problems. So that removing of that
> complex type from the type map is not a good idea. So, that line has
> been commented out in the releases after 1.1.1 and it has done the
> refinement in Type::setTypeNameForElementName().
>
> You should not get this problem, if you use Axis C++ 1.2 Alpha or later.
>
> Thanks,
> Amila.
>
>
>
> -----Original Message-----
> From: Dirk Wollscheid [mailto:wollsch@us.ibm.com]
> Sent: Monday, August 09, 2004 10:33 PM
> To: Apache AXIS C Developers List
> Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
>
>
> Samisa,
>
> I attached a zip file with the WSDLs to the bug (AXISCPP-96 ) in JIRA.
>
> wstx-soap_lit_coord.wsdl is the binding that I created myself. The other
> files are standard, except I modified them for better WS-I compliance
> (the standards team is picking up those changes).
>
>
> The original standards files can be accessed with these URLs (Note:
> There's no binding defined - only port types)
> http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.wsdl
> http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.xsd
> http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.wsdl
> http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.xsd
>
> Thanks, Dirk
>
> Dirk Wollscheid
> DB2 Webservices Development and other Database/Java/XML stuff
> email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> "They say that time changes things, but you actually have to change them
> yourself. " - A. W.
> "You can hide what you know, but you can't hide what you don't know" -
> Unknown
> Please respond to "Apache AXIS C Developers List"
> <ax...@ws.apache.org>
> To: Apache AXIS C Developers List <ax...@ws.apache.org>
> cc:
> Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
>
>
>
> Hi Dirk,
> Axis C++ team is currently working on the tool to implement some new
> features.
>
> The compilation problem is a known bug. This comes due to the way
> 'ANON_TOKEN' constant,
> defined in SymbolTable class of Axis Java, is handled from Axis C++
> WSDL2Ws java tool. The team is
> aware of the problem and this will hopefully be solved soon.
>
> The generation exceptions could well be due to the fact that some of the
> WSDL features used in
> the WSDL file that you use not being supported by the Axis C++ WSDL2Ws
> implementation as yet.
>
> Please send the URL of the WSDL file, so that I could have a look on
> what is going wrong.
> Thanks,
> Samisa...
>
> --- Dirk Wollscheid <wo...@us.ibm.com> wrote:
>
> > Hi, I'm playing with the WS-Transaction WSDLs and axis-c. I want to
> > generate client and server code for these WSDLs.
> >
> > I've tried both the V1.2 and today's CVS version. There are some
> runtime
> > errors and also some compile errors.
> >
> > I initially reported this in this bug
> > http://nagoya.apache.org/jira/browse/AXISCPP-96 . This was with V1.1
> and
> > yesteray I updated the bug with the information using axis-c V1.2
> >
> > I can provide the WSDLs and any other information that's necessary to
> > investigate and fix this.
> >
> > Thanks, Dirk
> >
> > Dirk Wollscheid
> > DB2 Webservices Development and other Database/Java/XML stuff
> > email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> > "They say that time changes things, but you actually have to change
> them
> > yourself. " - A. W.
> > "You can hide what you know, but you can't hide what you don't know" -
> > Unknown
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Amila Rathnayake <am...@opensource.lk>.
Hi Dirk,
According to your previous mail and the bug reported in Jira
(http://nagoya.apache.org/jira/browse/AXISCPP-96), it has mentioned that
the problem seems to be in the line
this.typeMap.removeType(qname);
in the method of ;
WSDL2Ws::getServiceInfo
and also that you are using Axis C++ 1.1.1
Yes, you are correct and there is a problem in that line in Axis C++
1.1.1.
When we use a wsdl in wrapped style, then there may be places where it
has defined non-named complex types but actual definition of that type
is also there in side of that complex type and it is actually a simple
type. So in this case we don't need to generate separate type for that
complex type and have to remove that from the TypeMap. Therefore to
cater this scenario it has inserted that line in the earlier versions of
Axis. Here is an example for that case;
<types>
<xsd:schema targetNamespace="http://www.sample.org/" >
<xsd:element name="countWords">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="words" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</types>
But there are some wsdl's that has given a name for that inner complex
type and will refer that complex type from other places in that wsdl by
its name. Then if we remove the type created for that complex type from
the TypeMap then it will cause other problems. So that removing of that
complex type from the type map is not a good idea. So, that line has
been commented out in the releases after 1.1.1 and it has done the
refinement in Type::setTypeNameForElementName().
You should not get this problem, if you use Axis C++ 1.2 Alpha or later.
Thanks,
Amila.
-----Original Message-----
From: Dirk Wollscheid [mailto:wollsch@us.ibm.com]
Sent: Monday, August 09, 2004 10:33 PM
To: Apache AXIS C Developers List
Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
Samisa,
I attached a zip file with the WSDLs to the bug (AXISCPP-96 ) in JIRA.
wstx-soap_lit_coord.wsdl is the binding that I created myself. The other
files are standard, except I modified them for better WS-I compliance
(the standards team is picking up those changes).
The original standards files can be accessed with these URLs (Note:
There's no binding defined - only port types)
http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.wsdl
http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.xsd
http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.wsdl
http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.xsd
Thanks, Dirk
Dirk Wollscheid
DB2 Webservices Development and other Database/Java/XML stuff
email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
"They say that time changes things, but you actually have to change them
yourself. " - A. W.
"You can hide what you know, but you can't hide what you don't know" -
Unknown
Please respond to "Apache AXIS C Developers List"
<ax...@ws.apache.org>
To: Apache AXIS C Developers List <ax...@ws.apache.org>
cc:
Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
Hi Dirk,
Axis C++ team is currently working on the tool to implement some new
features.
The compilation problem is a known bug. This comes due to the way
'ANON_TOKEN' constant,
defined in SymbolTable class of Axis Java, is handled from Axis C++
WSDL2Ws java tool. The team is
aware of the problem and this will hopefully be solved soon.
The generation exceptions could well be due to the fact that some of the
WSDL features used in
the WSDL file that you use not being supported by the Axis C++ WSDL2Ws
implementation as yet.
Please send the URL of the WSDL file, so that I could have a look on
what is going wrong.
Thanks,
Samisa...
--- Dirk Wollscheid <wo...@us.ibm.com> wrote:
> Hi, I'm playing with the WS-Transaction WSDLs and axis-c. I want to
> generate client and server code for these WSDLs.
>
> I've tried both the V1.2 and today's CVS version. There are some
runtime
> errors and also some compile errors.
>
> I initially reported this in this bug
> http://nagoya.apache.org/jira/browse/AXISCPP-96 . This was with V1.1
and
> yesteray I updated the bug with the information using axis-c V1.2
>
> I can provide the WSDLs and any other information that's necessary to
> investigate and fix this.
>
> Thanks, Dirk
>
> Dirk Wollscheid
> DB2 Webservices Development and other Database/Java/XML stuff
> email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> "They say that time changes things, but you actually have to change
them
> yourself. " - A. W.
> "You can hide what you know, but you can't hide what you don't know" -
> Unknown
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Re: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Dirk Wollscheid <wo...@us.ibm.com>.
Samisa,
I attached a zip file with the WSDLs to the bug (AXISCPP-96 ) in JIRA.
wstx-soap_lit_coord.wsdl is the binding that I created myself. The other
files are standard, except I modified them for better WS-I compliance (the
standards team is picking up those changes).
The original standards files can be accessed with these URLs (Note:
There's no binding defined - only port types)
http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.wsdl
http://schemas.xmlsoap.org/ws/2003/09/wsat/wsat.xsd
http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.wsdl
http://schemas.xmlsoap.org/ws/2003/09/wscoor/wscoor.xsd
Thanks, Dirk
Dirk Wollscheid
DB2 Webservices Development and other Database/Java/XML stuff
email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
"They say that time changes things, but you actually have to change them
yourself. " - A. W.
"You can hide what you know, but you can't hide what you don't know" -
Unknown
Please respond to "Apache AXIS C Developers List"
<ax...@ws.apache.org>
To: Apache AXIS C Developers List <ax...@ws.apache.org>
cc:
Subject: Re: Problems with WS-Transaction WSDLs and WSDL2Ws
Hi Dirk,
Axis C++ team is currently working on the tool to implement some new
features.
The compilation problem is a known bug. This comes due to the way
'ANON_TOKEN' constant,
defined in SymbolTable class of Axis Java, is handled from Axis C++
WSDL2Ws java tool. The team is
aware of the problem and this will hopefully be solved soon.
The generation exceptions could well be due to the fact that some of the
WSDL features used in
the WSDL file that you use not being supported by the Axis C++ WSDL2Ws
implementation as yet.
Please send the URL of the WSDL file, so that I could have a look on what
is going wrong.
Thanks,
Samisa...
--- Dirk Wollscheid <wo...@us.ibm.com> wrote:
> Hi, I'm playing with the WS-Transaction WSDLs and axis-c. I want to
> generate client and server code for these WSDLs.
>
> I've tried both the V1.2 and today's CVS version. There are some runtime
> errors and also some compile errors.
>
> I initially reported this in this bug
> http://nagoya.apache.org/jira/browse/AXISCPP-96 . This was with V1.1 and
> yesteray I updated the bug with the information using axis-c V1.2
>
> I can provide the WSDLs and any other information that's necessary to
> investigate and fix this.
>
> Thanks, Dirk
>
> Dirk Wollscheid
> DB2 Webservices Development and other Database/Java/XML stuff
> email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> "They say that time changes things, but you actually have to change them
> yourself. " - A. W.
> "You can hide what you know, but you can't hide what you don't know" -
> Unknown
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Re: Problems with WS-Transaction WSDLs and WSDL2Ws
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Dirk,
Axis C++ team is currently working on the tool to implement some new features.
The compilation problem is a known bug. This comes due to the way 'ANON_TOKEN' constant,
defined in SymbolTable class of Axis Java, is handled from Axis C++ WSDL2Ws java tool. The team is
aware of the problem and this will hopefully be solved soon.
The generation exceptions could well be due to the fact that some of the WSDL features used in
the WSDL file that you use not being supported by the Axis C++ WSDL2Ws implementation as yet.
Please send the URL of the WSDL file, so that I could have a look on what is going wrong.
Thanks,
Samisa...
--- Dirk Wollscheid <wo...@us.ibm.com> wrote:
> Hi, I'm playing with the WS-Transaction WSDLs and axis-c. I want to
> generate client and server code for these WSDLs.
>
> I've tried both the V1.2 and today's CVS version. There are some runtime
> errors and also some compile errors.
>
> I initially reported this in this bug
> http://nagoya.apache.org/jira/browse/AXISCPP-96 . This was with V1.1 and
> yesteray I updated the bug with the information using axis-c V1.2
>
> I can provide the WSDLs and any other information that's necessary to
> investigate and fix this.
>
> Thanks, Dirk
>
> Dirk Wollscheid
> DB2 Webservices Development and other Database/Java/XML stuff
> email: wollsch@us.ibm.com, phone: 1.408.463.2802, T/L: 543.2802
> "They say that time changes things, but you actually have to change them
> yourself. " - A. W.
> "You can hide what you know, but you can't hide what you don't know" -
> Unknown
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail