Thanks Gennady and Bob Lazarski for your help and pointers. My thoughts - Axis1 was tightly tied to JAX-RPC which determined the mapping from xml types to java. Even with the flexible databinding in axis2, some backward compatibility of axis1 code could have been maintained had the support to jaxme/jaxbri been complete (with unwrapping and all that). But probably that was not one of the design goals for axis2.
- Vish. ________________________________ From: Gennady Shumakher [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 12:57 AM To: [email protected] Subject: RE: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String Hi Vish, I faced the similar issues during evaluation of migration of our project from axis1 to axis2. As far I understand the issue here is that wsdl2java generation frameworks and databinding techniques don't have the strict unification of the way the code is generated. So even switching from one data binding to another would cause the need of code modifications since the generated complex data types are exposed in completely different API manner. (ADB - new SomeType(); XmlBeans - SomeType.Factory.newInstance()). To switch easily between data binding methods the one could consider code2wsdl path. Regarding the options you mentioned according to 1.3 documentation jaxme and jaxbri are in experimental phase. Gennady ________________________________ From: Pantvaidya, Vishwajit [mailto:[EMAIL PROTECTED] Sent: Monday, October 01, 2007 23:32 To: '[email protected]' Subject: RE: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String Actually I do see that the complex types are getting generated - but the "-f" option seems to be working erratically, because of which those types got generated with a "src" folder at the topmost level. But unwrapping does not work with jaxme/jaxbri/ADB. My takeaway from this exercise: Axis2 wsdl2java cannot generate same code like axis1 even if wsdl remains same and irrespective of the value of the "-d" wsdl2java option. Just migrating to axis2 forces people to use xmlbeans, adb, etc, and make change in the webservice implementation to handle, for example, xmlbeans.XmlString instead of java.lang.String. So my options are to: 1. use jaxme/jaxbri with wrapper classes even for simple webservice operations like login, etc 2. use xmlbeans and change my axis1 implementation to handle XmlString instead of java String. Any suggestions/thoughts/corrections? ________________________________ From: Pantvaidya, Vishwajit Sent: Monday, October 01, 2007 12:01 PM To: [email protected] Subject: RE: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String Hi Amila, Let me know if I am doing anything wrong here or if I need to change anything. - Vish. ________________________________ From: Pantvaidya, Vishwajit Sent: Friday, September 28, 2007 5:24 PM To: 'Amila Suriarachchi' Subject: RE: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String I also tried using jaxb hoping that it would directly map to java types - found 2 problems there. 1. axis2 does not support unwrapping for jaxb - why is that? 2. for the same wsdl, I emailed you, it created an interface as follows: public com.selectica.ws.ecm.wsdlgen.OperationStatusElement Upload ( com.selectica.ws.ecm.wsdlgen.UploadRequestElement uploadRequestElement ); But it did not create the class for the complex types com.selectica.ws.ecm.wsdlgen.UploadRequestElement and OperationStatusElement. Am I doing anything wrong here or is there a problem with the axis2 jaxb support? - Vish. ________________________________ From: Pantvaidya, Vishwajit Sent: Friday, September 28, 2007 1:29 PM To: 'Amila Suriarachchi' Subject: RE: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String For this wsdl - it creates interface as follows: public com.selectica.ws.ecm.wsdlgen.OperationStatusElementDocument Upload ( org.apache.xmlbeans.XmlString sessiontoken, org.apache.xmlbeans.XmlString trackingnumber, org.apache.xmlbeans.XmlInt version ); So the unwrapping here is okay - but I need java.lang,String params instead of xmlbeans.XmlString. I know that XmlString contains a string finally - but I do not really need that additional wrapper. Is this happening because of the bindings functionality introduced in axis2? Is it possible in axis2 to do wsdl2java using only POJO types? ________________________________ From: Amila Suriarachchi [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 2:58 AM To: [email protected] Subject: Re: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String On 8/23/07, Pantvaidya, Vishwajit <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: Tried scomp with xmlbeans 2.2.0 (same version as bundled with axis2) - it gives error "error: invalid.document.type: Document is not a wsdl file". But coming back to original problem - the wsdl used to process fine with axis1 resulting in interface with parameters of java types. Hasn't that been retained in axis2? Tried wsdl2java with ADB to see if that gives me what I want. That also completed fine - but resulting classes had all complex type params with generated types. So I tried the -uw option - hoping it will unwrap those. But now I get error org.apache.axis2.wsdl.codegen.CodeGenerationException: Unsupported Schema format for unwrapping! found unknown type but expected Element this means you have a choice or all type in your complex type. unwrapping works with the document literal type services. if you can send your wsdl I can check. org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.processXMLSchemaSequence(SchemaUnwrapperExtension.java:370), org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.handleAllCasesOfComplexTypes(SchemaUnwrapperExtension.java:198), org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.walkSchema(SchemaUnwrapperExtension.java:143), org.apache.axis2.wsdl.codegen.extension.SchemaUnwrapperExtension.engage(SchemaUnwrapperExtension.java:94), org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:218) Any idea what this is about? Is -uw option the right one? What is difference between that and -u? It is not very clear from the wsdl2java reference. -u let you generate seperate classes. - Vish. ________________________________ From: Amila Suriarachchi [mailto:[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>] Sent: Wednesday, August 22, 2007 8:56 PM To: [email protected]<mailto:[email protected]> Subject: Re: [Axis2]wsdl2java with xmlbeans creates interface with xmlbeans.XmlString instead of java.lang.String can you generate the code using xmlbeans scomp command and see what is the type? anyway I think XmlString contanins a string inside it. Amila. On 8/23/07, Pantvaidya, Vishwajit <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: I think I saw someone with same problem but cannot locate that message. My axis2 1.3 wsdl2java with xmlbeans is completing successfully. But the generated interface has methods with parameters of type xmlbeans.XmlString instead of java.lang.String. My expectation was it would map primitives to java datatypes and create xmlbeans for complex types. Is this not the case? Do I need to switch to ADB to get params with java types? -- Amila Suriarachchi, WSO2 Inc. -- Amila Suriarachchi, WSO2 Inc.
