Sanjiva, Thanks for your reply. Here are some thoughts on improving codegen's extensibility. They're from my perspective trying to extend WSDL2.
It would be great to have some documentation describing codegen's extension architecture. Woden has a very valuable wiki page at http://wiki.apache.org/ws/FrontPage/Woden/WSDLExtensions that we used to successfully add extensions. For Axis2, we're working our way through the code to learn how it works. It would be helpful to have something like Woden has. More Javadoc in codegen would also help. The WSDL2 working group has done a nice job of segregating the work into the Core spec and the Adjuncts spec. I think it would be valuable to reflect this in the code. As someone trying to extend codegen, I'd prefer not to modify codegen framework code because it does most of what I need. Also, if I change it then I have my own version and have to periodically check it against the official version and copy over any bug fixes. That gets tedious and error-prone quickly. It would help to refactor some code to modularize support for the main extension mechanisms of WSDL2: styles, MEPs, and bindings. Currently, the code supports those that are defined in WSDL2 Adjuncts, but it's not easy to add support for others since it's often the case that codegen framework classes also contain Adjuncts-driven code (e.g. SOAP and HTTP bindings, MEPs). Examples are WSDL20ToAxisServiceBuilder and AxisServiceBasedMultilanguageEmitter. It might be easier to understand and maintain the framework classes if logic specific to Adjuncts items were factored out to classes devoted to them and invoked via lookups driven by a properties file, like codegen-config. An example might be a "BindingProcessor" interface with a SOAP implementation class and an HTTP implementation class. WSDL20ToAxisServiceBuilder's "processBinding" method could do a lookup of a binding URI to find a BindingProcessor and delegate the SOAP or HTTP work to the appropriate BindingProcessor. I think this would be preferable to users hand-editing WSDL20ToAxisServiceBuilder. AxisServiceBasedMultiLanguageEmitter's generateMethodElement has a similar mixing of framework and Adjuncts work. A properties file might also be leveraged to register the mapping of MEP URIs to AxisOperation sub-classes. This would eliminate the need for users of the framework to directly modify AxisOperationFactory to add new <MEP, AxisOperation> mappings. This thread started with my request to have the value of the WSDL2 "style" attribute available to the XSLT templates. I like the XSLT template approach. I believe it can be improved by ensuring that when the Emitter produces the DOMs for transformation it doesn't assume that the templates to be used in the next step are those that shipped with Axis2. Codegen-config.properties allows users to introduce others, so I think it's reasonable for template developers to expect that items defined in WSDL2 Core should be visible somewhere in those DOMs. This includes the "style" attribute as well as items like message labels (see http://marc.info/?l=axis-dev&m=118019901127507&w=2) I've covered a lot here and offered some possible solutions, but I think the first step is to look at the codegen architecture and its extension development process covering new MEPs, new styles, and new bindings. I hope these comments are useful. Peter On 6/1/07, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
Peter Danielsen wrote: > > I'm quite interested in Axis2's plans for the accommodation of 3rd > party MEPs, styles, and bindings allowed by WSDL2. We carefully designed Axis2 to support 3rd party MEPs, styles and bindings. Please let us know areas where you are having trouble with as that shouldn't be the case! Specific suggestions greatly appreciated .. and of course code is better! Thanks, Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Director; Open Source Initiative; http://www.opensource.org/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
