Can we please stop this thread?
If you find the documentation lacking, do something about it. There are many
people out there who
have no problems using Axis, myself included. If you find the documentation
lacking, improve it
and submit it back to the project. If you have a better way to design the
code, give the code to
the project so the committers can look at it. The old excuse: "I dont have
time to do it" just
does not fly. It is easy to sit and complain about things, but much harder to
provide a solution.
This is a volunteer project.
Bottom line is...if you can not figure the project out, dont use it. Pay
Microsoft, BEA, IBM, or
whoever, tons of money for their product, support, and documentation. For some
companies that is
the way to go. For others, it is not.
--- Guy Rixon <[EMAIL PROTECTED]> wrote:
> 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
>
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
