Design of wsimport

[jason.greene]

I thought I would outline the plan for the JAX-WS wsdl->java tool (wsimport).

API Dependencies

Unlike the java to wsdl processing, wsimport is more isolated and has minimal API requirements from core:

1. 
   
2. WSDLDefinitions - Our WSDL API is the main source, as this tool largely has 1 input, the WSDL file.
   
3. JAXB XJC API - This will be needed to generate Java types for all schema types contained in the WSDL.
   
4. JAXB Code Model API - Since the XJC API returns instances of JCodeModel, we might as well use it for generating the remaining Java artifacts.
   
5. JDK Compiler or Javassist - We will either need to invoke the JDK compiler or build a JCodeModel to bytecode translator using javassit
   
   
   Key Tasks
   
   The following are the major tasks for implementing this tool:
   
   1. 
      
   2. Enhance WSDLDefinitions - The WSDLDefinitions API needs to be enhanced to handle the custom jaxws binding extension elements. Also WSDL11Reader needs to be enhanced to take a DOM view of all schema elements and make them available as a DOMTypes object (already exists for generation now).
      
   3. Implement Binding File Processing - A JAX-WS binding file parser needs to be implemented. This binding file allows you to specify customizations that apply to the WSDL file, but without having to modify the WSDL file.
      
   4. WSDL XPath Modifcation Phase - Since the binding file uses xpath expressions, we must first read the WSDL file into a DOM tree, then perform the XPath modifications to obtain the inlined version. After this the WSDL11Reader will produce a WSDLDefinitions model that contains the additional JAX-WS metadata.
      
   5. Implement Core Processing Engine - This component will be responsible for interpreting the resulting metadata, and generating artifacts through JAXB XJC and the JAXB Code Model API that conform to the WSDL to Java portion of the specification.
      
   6. Implement Source and Bytecode generation - At the end of the processing phase, bytecode and optionally source will need to be written to disk. The code model API has the capability to generate the source; however, it has no direct bytecode generation capability. This would have to be implemented by us, or we could just invoke the compiler and delete the source files if they aren't desired by the user.
      
   7. API - A simple API will need to be developed that takes the input options, and returns the list of artifacts generated, as well as any error or warning conditions that occurred.
      
   8. Command line tool - This will be a simple command line tool that uses the above API to perform the required processing.
      
   9. ANT Task - A simple ant task that offers the same options needs to be developed. As in the command line tool, it should use the above API.
      
      

[thomas.diesler]

Good work, thanks.

[dwin]

Just curious, when do you guys think this will be released?

[dwin]

Just a neat feature to include,

it'd be nice if xs:annotation <xs: documentation> gets translated into java docs.

[jason.greene]

The JAXB XJC api does this, so it will be there ;)