Axis code generation module extension

Question

In short, what I want to achieve is the ability to run wsdl2java and generate additional code. Has anyone done this and can offer hints / tips / advice, has someone done something similar with a different approach, will one go further than the question (much further)?

In long form:

Background:

We have third-party software that is widely used in many projects, but it does not have the ability to directly integrate with web services. With that in mind, we take wsdl, generate the client, and then we have a lot of template code that sits on top to provide integration. I spent some time lining, but I want the whole pig.

Current position:

I wrote a simple first-generation code generator that handles the creation of 95% of the code, but it reads in the manually written xml config, outputs the code using FileWriter (eugh), but I still need to write code to link it, passes the information to / from actual webservice client code. It was just a quick and dirty decision, as I needed it quickly, and also act as a POC.

Approach to solving this issue: I collect it in due time solely because I consider it an interesting problem, but, as such, I do not want to spend a lot of things on a dead end approach.

I believe that the way to achieve my goal is to write the extension of the code generation module as described here http://wso2.org/library/35 , I believe in writing this extension, I will get access to the wsdl axis model and can apply my own xslt.

If you agree and have done this, is there any advice you want to share or useful resources that you can point me to.

If you do not agree with my approach, I would be grateful for a brief review (I do not want to waste your time) on why and the proposal for a new agreement.

Answer 1

Further research showed that the way is to create a new CodeEmitter based on the AxisServiceBasedMultiLanguageEmitter.

Unfortunately, this project was completed, as there was no longer a requirement to create web service clients. The third part of the software has released a new version that allows you to directly use web services.

Answer 2

I have never expanded the Axis2 WSDL2Java issuer, so I don’t know how much flexibility you would benefit from this. In the article you are referring to, you can easily resort to the generation process. It really depends on what you have to generate. I recently had to create template code from database schemas and WSDL, and I used a mixed approach:

• Groovy

Groovy is great for rapid prototyping and templates. For example, you can collect information from a database or Wsdl and emit code based on a template. Here you can see some examples: http://groovy.codehaus.org/Groovy+Templates

• API PMD

PMD is a tool for scanning Java code and reporting potential problems. It also provides an API for code analysis using XPATH and has a very rich model for working. You can do things like:

final Java15Parser parser = new Java15Parser(); final FileInputStream stream = new FileInputStream("VehicleServiceType.java"); final Object c = parser.parse(new InputStreamReader(stream)); final XPath xpath = new BaseXPath("//TypeDeclaration/Annotation/NormalAnnotation[Name/@Image = 'WebService']", new DocumentNavigator()); for (final Iterator iter = xpath.selectNodes(c).iterator(); iter.hasNext();) { final Object obj = iter.next(); // Do code generation based on annotations... } 

Personally, I found that a mixed approach works better than a monolithic one. Code generation is often an art, not a science. One more thing: in my current project, I'm looking at Python for (simple) code generation. It has a very good template library ( jinja ), but I would not recommend it for parsing Java code.

Hope this help!

Answer 3

You have already started writing a code generator to achieve your goal in order to try to continue this path. The codemodel library is a pretty amazing library for generating code. I only recently used it to generate code, and that was very good.

I suggest you give this codemodel library an attempt to generate the required code. This is a codemodel library written for jaxb wsdl for a java compiler.

Answer 4

We have used wsdl2java many times (but along the 1.4 axis). My tips:

1 use complex / structured types as arguments for operations, for example. resetWidget (widgetStruct), where the widgetStruct class contains the fields widgetId, widgetName, widgetType, etc. instead of resetWidget (arg1, arg2, arg3 ..). So next year, when you expand WSDL and add a few more parameters, all legacy codes will compile without having to distribute all your methods. This approach was actually imposed on us because the other (old) WSDL tool did not generate responses correctly if we passed all the fields as parameters.

2 Put all your business logic in other classes. Therefore, when you restore the skeleton, you can simply return a few lines of code instead of updating huge pieces of code.

Perhaps some of these issues have been resolved in Axis2.