Just over 6 months since the original 1.0 release, we are very proud to announce the release of Apache Axis2 version 1.1
Apache Axis2 is a complete re-design and re-write of the widely used Apache Axis engine and is a more efficient, more scalable, more modular and more XML-oriented Web services framework. It is carefully designed to support the easy addition of plug-in "modules" that extend its functionality for features such as security and reliability.
Modules supporting WS-Security/Secure-Conversation (Apache Rampart), WS-Trust (Apache Rahas), WS-Reliable Messaging (Apache Sandesha) and WS-Eventing (Apache Savan) will be available soon after the Apache Axis2 1.1 release. Please see these projects' own sites for further information.
Major Changes Since 1.0:
- Significantly improved documentation
- Significantly improved support for POJO services and clients
- Significantly improved support for Spring services
- Significantly improved Axis Data Binding (ADB) to increase schema coverage and overall stability
- Improved service lifecycle model
- Improved JMS support
- Improved handler and module interfaces
- Improved Eclipse and Idea plugins
- New Attachments API for sending & receiving MTOM and SwA attachments
- Built in support for WS-Policy via Apache Neethi
- Added support for unwrapping Web service requests
- Fixed tons of small and not-so-small bugs
- Major refactoring of release structure to make usage easy
Known Issues and Limitations in 1.1 Release:
- Unwrapping of response messages (coming in 1.2)
- JSR 181/183 Annotation support (coming in 1.2)
- JaxMe and JAXBRI data binding support is experimental
Apache Axis2 1.1 is a major new release compared to Axis2 1.0. We are striving for a simple and happy first time user experience as well as a satisfying experienced user experience with this release. We welcome any and all feedback at:
Thank you for your interest in Apache Axis2!
The Axis2 Development Team
...is now so non invasive that a SOAP framework has to provide support for it! In the headline! I am indeed impressed.
In my actual project I will work with xfire, you think it's a good idea?
since Axis2 WS development is no more "pain in the ass" with it. Well, there are significant differences between Axis2 and XFire but if you are familiar with XFire and XFire meets all your requirements use it. Using the tool you are familiar with is always the best choice, assumed that it provide all feature you need.
As someone who had to deliver a SOAP gateway using Axis2 for a major investment bank (i.e., no choice), I have this message:
Fast. Whatever the version: do yourself a favor. Maybe, consider XFire, dunno. The functionality/code quality of Axis2 is like nothing like I've seen before. The comments stating "...but, I don't care" have been reported to the management. The implementors have no slightest idea of what they were doing. Based on their code/design, NO CLUE whatsoever!
Sounds not too good ;-). i'm thinking of using Axis2 for a new Project with a lot of heavy(!) used webservices.
so can you be a little bit more precise? (some examples, etc.)
Try reading some of the documentation and you'll get a sense for the problem with this tool. It's a shame, because it does have promise.
please contact me at serge4bus at usa dot net to discuss
Well I'm sorry you had such a bad experience with Axis2 1.0. I know its probably too late for you now, but the 1.1 release is a very different beast from the 1.0 release. If you do have a bit of time please do give it a whirl and let us know what you think works and most importantly doesn't work.
If you saw comments saying "... but, I don't care" can you please report them to us? I just did a recursive grep on the 1.1 src tree and found 5 occurrences of the string "don't care" and they all seem reasonable scenarios being documented as not relevant for the condition. I would appreciate any concrete pointers you can give.
Also, as an open source project we certainly appreciate any help you can give to fix problems.
Does it support WSDL 2.0? In the key features section WSDL 2.0 is listed, but in the specifications supported section only WSDL 1.1 is listed.
I have a couple of web service applications deployed with Axis2 and it wasn't that bad. We chose Axis2 because we wanted to use JiBX for marshalling and XFire wasn't quite there yet. We probably aren't stretching the limits of Axis2, but with a little effort, we got it to work.
We use the Open Travel Alliance schema, which causes a lot of tools to blow up. If I remember right, Axis2 barfed while trying to generate ADB classes from it. I ended up writing a code generator that could parse the OTA schema and generate Java classes and a JiBX binding. We wanted to go with JiBX anyway, because in testing it was significantly faster than ADB at marshalling large objects.
Axis2 1.0 shipped with a beta version of JiBX, I was able to replace the JiBX jars in the axis2.war file to use a released version.
We are using a DataPower box for XML validation, transformation, authentication, and load balancing. That may have alleviated some of the headaches with Axis2.
We run Axis2 under Tomcat 5.5. The hot deployment doesn't work very well, so we use a more manual process of installing the aar files and restarting the server. The DataPower box takes the server out of the balancing pool while it is restarting. It may be because we aren't using Axis2's normal installation mechanism, but we find that over time, the Tomcat temp space gets pretty big with jar files left over from previous versions of our services.
There were some weird class loading issues, some of our framework classes couldn't load resources with getResourceAsStream(). We had to call: Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
to fix it. We preserve the original and restore it at the end of the method.
When implementing the web service, we subclass the Skeleton class that is generated, so we don't worry about it being overwritten by wsdl2java. We use XSLT in our ant build to make the appropriate change in services.xml (where we also take the opportunity to label the service scope as "application" - axis2 defaults to "request" which creates a new instance of the web service object at each invocation).
We feel now like we have gotten most of the bumps smoothed out.