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
