Hi Todd; Are referring to Call/MEPClient API or Generated Stubs. We do not force you to use the OM* API unless you need XML level support. You can use the generated Stubs and Client s and work with out seen a OMElement at all.
Q) are you happy with Axis1.x API? what you had there and missing at Axis2 If it is good architecturally .. we can fix the client API If only you can provide constructive comments. Remember lot of developers has different opinions about it .. some quite opposite. Tell us 1) Exactly in detail what are the problems? 2) What your expected scenarios .. with example may be 3) Suggestions to how to fix current API If you do, we can discuss and improve Axis2, if you arguments are reasonable we love to make the fixes. On the other hand if the Xfire serve you better please go for it. If you comment please be constructive ..random opinions do not help anybody!! Thanks Srinath On 12/15/05, Todd Orr <[EMAIL PROTECTED]> wrote: > The more I learn about Axis2, the less appealing it is. It seems to be giant > leap backwards. Why is coding using OMElement (and the other OM... objects) > a better approach than deploying a POJO? This is a huge pain. Not to mention > the deployment issues that I've already run into. Based on the documentation > I feel as though Axis2 is a step forward architecturally, but extremely weak > in user friendliness. For this reason I've been finding myself more > interested in XFire. It has many features of Axis2, yet is extremely easy to > create Web services with. Why would the Axis2 team go in this > anti-productivity direction? >
