Apache CXF 2.4.0 Released!

After 6 months of development, the Apache CXF team is proud to announce that 2.4.0 is now released. (official announcement) This version was a fairly large undertaking and has a bunch of significant new features.

• Security: WS-Security enhancements were a major theme for this release. It mostly started as work to get a new version of Apache WSS4J (version 1.6) integrated into CXF but really turned into a bunch of major updates to WSS4J and even larger enhancements to CXF. The primary “driving feature” was support for SAML2 tokens. In the end, we support SAML2 tokens, but also have much better configurability of the keystores, more consistent callback handling, much better token validation API’s and capabilities, the ability to “fail fast” in many cases when security issues are encountered, etc… I HIGHLY recommend reading through Colm’s blog to discover all the new features in WSS4J that were developered to support CXF.
• Performance and memory footprint: A significant amount of work was put into the startup procedures in CXF to reduce startup time and lower the memory footprint. As part of this, the dependency on Spring to wire together CXF has been greatly reduced. Now, almost all features of CXF can be used without Spring. Previously, many of the advanced features like WS-SecurityPolicy and WS-RM and such required Spring. In all, a particular test case I have that deploys over 200 services within over 75 wars can now deploy and run with MUCH less memory than before (required -Xmx drops from 192M to 96M and startup time in tomcat drops from about 50 seconds to 20). Note: with this change came the removal of almost all the META-INF/cxf/cxf-extension-*.xml files. MUCH easier to configure now as well.
• HTTP transport refactoring Related to the Spring stuff, the HTTP transport was refactored to remove the requirement of Spring to select “which” http transport. Previously, the user really need to select (by importing the appropriate spring file) either the servlet version, the embedded jetty version, or the OSGi version. There is now a single http transport that handles all three cases. You can even mix/match with some some services that deploy on the servlet provided context, but others that spin up an embedded jetty instance on a different port.
• JiBX databinding: a Google Summer of Code project from last year, CXF now supports using JiBX in addition to JAXB, XMLBeans, and SDO.
• Log browser: another Google Summer of Code project resulted in a very nice web/rest based frontend to the logs produced by CXF. It’s a starting point for future admin related tasks, but is quite useful right now.
• Transformation feature: provides for a fast and effective way to transform inbound and/or outbound XML messages. There is a nice introduction to this on Sergey’s blog.
• OSGi improvements: A lot of stuff was done to make working with CXF in OSGi much better. The OSGi HTTP transport was already mentioned. We also added an Apache Karaf features file to help setup CXF in Karaf a lot quicker and easier. Finally, work was started (it’s a work in progress) to add Blueprint/Aries namespace handlers to allow deployment of services using Blueprint instead of Spring DM. Currently, the basic creation of clients and services works in Blueprint. Some of the more advanced configuration (most notable is the HTTPs configuration) is still being worked on.
• Work with Apache WebServices community: along with working closely with WSS4J as mentioned above, CXF developers also worked to drive changes in Neethi and XmlSchema. The result is much better collaboration between CXF and the WebServices communities and many hacks and workaround in CXF being removed as the fixes and changes were made in the underlying libraries.

As you can see, there was definitely a lot of exciting work put into 2.4.0. I definitley encourage forlks to read the migration guide for more information about the changes and the potential impact it has on users.

Another interesting thing I’d like to point out is how much this was a COMMUNITY effort. The features above were developed by a bunch of people in the community, not just a single person or company. While the security and performance work was primarily done by Talend employees, we also had major contributions from the GSoC students (2 students became committers), Benson Margulies did a lot of work getting XmlSchema 2.0 released and integrated, much of the Blueprint work is being done by Johan Edstrom as part of his work with Savoir Technologies, etc…

Of equal interest is who was NOT a driving force for this release: IONA/Progress/Fuse. Since CXF was started at Apache way back in 2006, the IONA/Progress/Fuse developers have been a primary driving force for new features and development in CXF. 2.4.0 really marks a major change from that. It’s not to say they haven’t been contributing to CXF, they definitely have. However, most of their contributions are more in the form of bug fixes and minor tweaks, not major new feature development. In my opinion, this a good thing for CXF and shows the value in the way Apache values the diversity of the community. In many cases, open source is about “scratching your own itch.” Basically, if you need something done or fixed, you do it and submit it to the project. Over time, in a healthy community, many of the original itches get scratched and those people move on, but new people come in with new ideas and requirements and drive furthur work. The mark of a healthy community is how open they are to such changes and how well the community adapts. CXF has adapted quite well.

Anyway, I definitely encourage everyone to upgrade to CXF 2.4.0 and experience the new features. All of this “goodness” will soon be available in Talend Service Factory and the other Talend offerings. Keep an eye out for it.