I concur. Good suggestions all. Kurt Olsen | Software Engineer| EzRez Software, Inc. 3465 Waialae Avenue, Suite 200 | Honolulu | HI | 96816 p 808-735-9260 x 238 | f 808-748-0488 [EMAIL PROTECTED] | www.ezrez.com
This message may contain confidential information. If you are not the intended recipient (or authorized to receive for the recipient) and received this message in error; any use, distribution or disclosure is strictly prohibited. Please contact the sender by reply email and delete all copies of this message from your computer system. The views and opinions expressed in this email are those of the sender and do not necessarily reflect the views or policies of EzRez Software, except when the sender expressly and with authority states them to be so. -----Original Message----- From: Guy Rixon [mailto:[EMAIL PROTECTED] Sent: Sunday, October 30, 2005 10:22 PM To: [email protected] Cc: [email protected] Subject: RE: I give up Three suggestions for improving the Axis experience: 1. More effort to documentation. The Axis 1 documents aren't yet sufficient to deal with use in a real project. Just expanding some of the Javadoc comments would help. In fact, providing or expanding the package.html files would be good, and maybe more palatable than reworking the xdocs. :) If someone did want to work on the xdocs, the reference guide to WSDD would be a good place to start. 2. Improve the error reports. Currently, when Axis goes worng (more commonly, when it is misconfigured) the error reporting isn't sufficient to diagnose the problem. Alternatively, provide tools that can inspect the configuration of a deployed service and explain what's wrong. 3. Provide an alternative to the current WSDL2Java to write stubs that use an external seralizer/deserializer mechanism (Castor, XMLbeans, JAXB). In my experience with Axis, the stubs are the valuable part and the Axis XML-mapping is redundant (duplicates mapping code we already have) unstable (bean classes incompatible between Axis versions) and fragile. Hence the move to XMLBeans in Axis 2, I guess...but maybe Axis 1 could be cleaned up too? What I have in mind is a stub-generation tool that takes a WSDL contract, a Java interface defining the API of the stub and a file of class/element mappings. It would generate stubs for which the API is entirely defined by the author of the client, and which can be rebuild to the same contract in the next version of Axis 1; WSDL2Java can't provide this stability of interface. You could provide a separate tool for creating data-binding beans if one were needed. This could generate the beans that WSDL2Java currently produces. It would also need to generate the class/element mapping-file. Guy Rixon [EMAIL PROTECTED] Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
