+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/
