Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 95848 invoked from network); 23 Aug 2004 05:52:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 23 Aug 2004 05:52:24 -0000 Received: (qmail 81097 invoked by uid 500); 23 Aug 2004 05:52:23 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 81029 invoked by uid 500); 23 Aug 2004 05:52:21 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 81002 invoked by uid 99); 23 Aug 2004 05:52:21 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received: from [66.218.78.145] (HELO web40608.mail.yahoo.com) (66.218.78.145) by apache.org (qpsmtpd/0.27.1) with SMTP; Sun, 22 Aug 2004 22:52:17 -0700 Message-ID: <20040823055216.26646.qmail@web40608.mail.yahoo.com> Received: from [203.143.12.118] by web40608.mail.yahoo.com via HTTP; Sun, 22 Aug 2004 22:52:16 PDT Date: Sun, 22 Aug 2004 22:52:16 -0700 (PDT) From: Samisa Abeysinghe Subject: RE: Problems with WS-Transaction WSDLs and WSDL2Ws To: Apache AXIS C Developers List In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 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 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" > > To: Apache AXIS C Developers List > 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: > > > > This type defines the fault code values for context-related faults. > > > > > > > > > > > > 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 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; > > > > > > > > > > > > > > > > > > > > > > > === message truncated === __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail