axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa_abeysin...@yahoo.com>
Subject RE: Problems with WS-Transaction WSDLs and WSDL2Ws
Date Mon, 23 Aug 2004 05:52:16 GMT
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 <wollsch@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" 
> <axis-c-dev@ws.apache.org> 
> To:     Apache AXIS C Developers List <axis-c-dev@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 <amilar@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

Mime
View raw message