Please upload a "svn diff" against Axis2 SVN after u open the JIRA bug.
thanks, dims On 4/6/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > +1 to "I guess the best would be to refactor the Axis2 implementation > and contribute it back to Axis2" > > Jira is the best way to get eyeballs on your problem :) > > -- dims > > On 4/6/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > Hi Everybody, > > Here is an attempt on the wrapper. I have created Java2WSDLGenerator > > interface and impl that wraps up the Axis2 implementation. This basically > > crunches the functionality of the Java2WSDLCodeGen, Java2WSDLBuilder and the > > Java2WSDL implementations of Axis under it. I have copied / refactored the > > Axis2 code into this single class that will act as a facade. From this > > point onwards, lower down the call trace stack, I have constrained myself > > to using Axis2 implementation as is. From here on I feel that any fix > > should go into Axis2 codebase itself. > > > > As far as this wrapper implementation is concerned I have put in another > > class called TuscanyJava2WSDL. This class will work with this > > Java2WSDLGenerator of ours, access the WSDL model and fix the model wherever > > required. As a started I have removed the redundant namespaces that used to > > get generated with the ns0, ns1 and ns2 prefixes. My find is, that these > > get generated only during the serialization of the Schema and is not > > originally a part of the Schema that is generated by the SchemaGenerator > > class... it seems to be the doing of SchemaSerializer in the ws.commons > > package. I have also fixed the "elementFormDefault" attributes. We could > > use this class a 'model fixer' at the present moment to go forward with > > Tuscany. In due course, as the Axis2 code is fixed we could cut out the > > fixes implemented in this class. > > > > Coming to the design of this wrapper I am not too comfortable with the > > design. For example I would prefer that the Java2WOMBuilder is the class > > called to generate the WSDL model after the validation of input arguments. > > I would prefer that Java2WOMBuilder uses the SchemaGenerator internally. I > > could not inherit the Java2WOMBuilder to do this myself because of the way > > its constructor and instance variables have been implemented. > > > > I guess the best would be to refactor the Axis2 implementation and > > contribute it back to Axis2. But then I am clueless about getting a break > > to do this... an earlier mail that I sent to the dev-team there regard the > > generation of the namespace has not evoked any reponse. > > > > So what is the community's take on this... should we go ahead and populate > > this wrapper with the fixes that we would need to go ahead with our release > > plans or should we wait to fix up Axis2 implementation and then use it. > > > > Here is the jar of classes that make up the wrapper... I have downloaded > > the Axis2 Source release as the binary release does not contain Java2WSDL. > > Please let me know your opinions on this... thanks. > > > > - Krish > > > > On 4/5/06, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > > > Venkata Krishnan wrote: > > > > Hi > > > > > > > > I have been looking into the Java2WSDL tool implementation in Axis. > > > > The generated WSDL for the Helloworld service seems to be comparable > > > > with what is there in the samples. There are some differences > > > > between the two though. Also when the targetnamespace is not input > > > > (i.e. user specified) the resultant wsdl is erroneous. This is also > > > > reported by others on the Axis2 Dev. Mailing Lists. I have attached > > > > the two wsdls just in case any of you want to take a look. > > > > (helloworld.wsdl is the one in the Tuscany Samples and > > > > HelloWorldServiceComponentImpl.wsdl is the AXIS2 > > generated WSDL). > > > There are some bugs in the WSDL generated by Axis2: > > > - Duplicate namespace prefix declarations for > > > http://www.w3.org/2001/XMLSchema in the generated XSD > > > - Incorrect elementFormDefault, attributeFormDefault and targetNamespace > > > attributes on the schema element. IMO they shouldn't have any namespace > > > prefix, my XSD validator flags them as errors, and I spent half an hour > > > in the XSD spec and couldn't find evidence that these attributes can > > > have a prefix... If any XSD expert in the group knows the answer please > > > jump in and help us decrypt the XSD spec :) > > > - Missing namespace prefix declaration in the WSDL for your XSD types > > > namespace... > > > > > > Do you think you could create JIRA issues in the Axis2 project for these > > > problems? > > > > > > > > > > > I was looking into how we could instrument the generated WSDL model > > > > (say) for adding additional namespaces, specifying the location > > > > address for the service, getting rid of some redundant namespaces that > > > > get generated and then finally correcting the errors. In the current > > > > implementation there is no way for the clients (like the Tuscany > > > > Runtime) to intercept this WSDL generation process and introduce the > > > > necessary customizations. For example if the generation process, at > > > > the highest level was clearly split into > > > > - parsing and validation of user inputs > > > > - generation of the WSDL Java model from the inputs (java classes > > > > that model the WSDL) > > > > - streaming of the model into an output stream > > > > with call backs to clients at the end of each phase, then it would be > > > > cleaner to introduce our customizations. > > > > > > > > The current implementation does have this separation of functions but > > > > then they are all nested level down the class that is available for > > > > the clients to use which is the Java2WSDL class. Hence instead of > > > > using the Java2WSDL class of Axis2 or the class one level below it for > > > > which there is no public access (the Java2WSDLBuilder), I am > > > > considering building our own wrapper that will, instead of just > > > > delegating to Java2WSDL of Axis2, will assemble the funtions provided > > > > by the various Axis2 classes (such as model generation, model writing) > > > > providing appropriate interception points for customizations. > > > > > > > > Does this make sense? Are they any other issues that I must watch out > > > > for in this regard? Any suggestions / comments on what I intend to do > > > > with respect to building the wrapper. > > > > > > > Yes it makes a lot of sense to me. You're right, Java2WSDL and > > > JavaWSDLBuilder do not provide the API we need, but the function is more > > > or less there in the underlying classes. Perhaps you could prototype the > > > wrapper in Tuscany first, then contribute it to Axis2 and work with them > > > to get a nice WSDL generation API in place? What do you think? > > > > > > The code in JavaWSDLBuilder.generateWSDL() is interesting. It actually > > > takes just a few lines of code to generate a WSDL from Java using the > > > Axis2 SchemaGenerator and Java2WOMBuilder. Here's a code snippet > > > inspired from the code in JavaWSDLBuilder, which illustrates this: > > > > > > String xsdTargetNamespace=" http://mytypes "; > > > String xsdNamespacePrefix="t"; > > > String serviceName="myService"; > > > String targetNamespace=" http://myservice";; > > > String targetNamespacePrefix="s"; > > > String wsdlPrefix="wsdl"; > > > Class myServiceInterface=AccountService.class; > > > > > > // Generate XML schema types for all the complex types > > > flowing through the business methods on my service interface > > > SchemaGenerator sg = new > > > SchemaGenerator(myServiceInterface.getClassLoader(), > > > myServiceInterface.getName(), xsdTargetNamespace, xsdNamespacePrefix); > > > XmlSchema schema = sg.generateSchema(); > > > > > > // Use the Java2WOMBuilder to build a WSDL object model > > > WSDLDescription wommodel = new Java2WOMBuilder( > > > sg.getTypeTable (), > > > sg.getMethods(), > > > schema, > > > serviceName, > > > targetNamespace, > > > targetNamespacePrefix).generateWOM(); > > > > > > // Tweak the generated WSDL model, for example if we just > > > want a WSDL portType, we can remove the generated bindings and services > > > // It would be better to change the Java2WOMBuilder to only > > > generate the portType in the first place, but this illustrates that you > > > can work with > > > // the generated WSDL model and adjust to look like you want > > > wommodel.getBindings().clear(); > > > wommodel.getServices().clear(); > > > > > > // Write the WSDL model into a WSDL 1.1 document > > > WOMWriter womWriter = > > > > > WOMWriterFactory.createWriter(org.apache.wsdl.WSDLConstants.WSDL_1_1); > > > womWriter.setdefaultWSDLPrefix(wsdlPrefix); > > > womWriter.writeWOM(wommodel, System.out ); > > > > > > I played a little bit with this code today to answer your question about > > > any other issues to watch out for... and I found a few more issues, > > > actually more than I wanted :) > > > - All XSD types are generated in a single namespace, even if you start > > > with Java classes from different packages. > > > - Java2WSDL + WSDL2Java do not round-trip at all. If you start from > > > Java, generate WSDL, then generate Java again, you get very different > > > results. Going from WSDL to Java and back to WSDL produces invalid XSD > > > complex types with names containing $ signs. > > > - I also ran into a confusing situation with method signatures. For > > > example from a getQuote(String symbol, String currency) method, > > > Java2WSDL generates a getQuote WSDL operation taking a single > > > getQuoteRequest element, containing child elements for symbol and > > > currency. Now if you give that WSDL operation to WSDL2Java again, you'll > > > end up with a new getQuote(GetQuoteRequest getQuote) method, very > > > different from the original getQuote method. I'll let you guess what you > > > get if you then give the generated Java interface to Java2WSDL again :) > > > > > > I suggest we work with the Axis2 team and open JIRAs for everything we > > > find rather than trying to work around these issues by tweaking the > > > generated WSDL object model. I'll create JIRAs for the problems I found > > > today. > > > > > > > Ofcourse, I am also aware of and will work on the fact that the java > > > > annotations in the component implementation should also be leveraged > > > > from, when generating the WSDL. > > > > > > > Yes, we'll need to support Java 5 annotations at some point. I am not > > > sure we need that right away, we can probably default the namespaces, > > > WSDL and XSD names from the Java names for now and add annotations > > > later. What do people in the group think? > > > > > > > Thanks > > > > - Krish > > > -- > > > Jean-Sebastien > > > > > > > > > > > > > > > -- > Davanum Srinivas : http://wso2.com/blogs/ > -- Davanum Srinivas : http://wso2.com/blogs/
