WildFly 9 and JBossWS 5, the future is coming...

After few months of silence, here we are again with some webservices updates. We've been working on next major release of JBossWS the whole spring and summer and few days ago the first Beta of JBossWS 5 has been released to the Maven repository.
So, what's new and great with JBossWS 5 ? The release notes for the first beta can be found on Jira as usual, however let's go through the main changes and improvements.

Apache CXF 3

The most important component upgrade with JBossWS 5 is the move from Apache CXF 2.7.x series to the 3.0.x series, which also pulls updates to Apache WSS4J 2.0.x and Apache Santuario 2.0.x. Apache CXF 3 brings a bunch of new features. The most notable one is probably the addition of WS-Security streaming support: a new StAX based implementation of WS-Security is available as an alternative to the existing DOM based one; the streaming implementation ensures better performances when dealing with large SOAP messages, as less memory is consumed to parse the message headers and the stack can completely avoid the message conversion to DOM if there's no other reason for doing that.
Among the other improvements in Apache CXF 3, a more complete support of WS-RM 1.1 is provided and a new asynchronous http transport is available.

WSDL soap:address rewrite improvements

JBossWS features a mechanism for rewriting the soap:address element in the WSDL that's published for both code-first and contract-first endpoint deployments. This is commonly used to control the endpoint address that's advertised when the actual application server instances are running behind load balancer or proxy hosts. Multiple options are available to define how the address computed by the container has to be tweaked to be a valid address for the user actually invoking the endpoint from outside of the server network. With JBossWS 5, few additional options have been added, like endpoint path rewrite rules (supporting SED scripts) and an attribute to force the address scheme (http or https) regardless of the transport security setup of the server.
Speaking of published WSDL manipulation, system property expansion is now also supported.

Default CXF bus selection strategy change

The concept of Apache CXF bus selection strategy has been introduced in one of the previous posts. With JBossWS 5, the default strategy for JAX-WS clients running in-container (that is in WildFly, perhaps invoked by a EE component like a servlet, EJB3 bean or CDI bean) is now TCCL_BUS. The change is going to ensure better performances, reducing the number of Bus creations and the amount of memory used for them. The reason for such a change stands in the container basically defining a different classloader for each deployment, which is usually the proper level of isolation for JAX-WS client busses. The user can still configure the server to use the previous default behavior.


The new JBossWS 5.0.0.Beta1 components, including the new Apache component dependencies, have been pushed to the current WildFly master. That basically mean that the great upcoming WildFly 9 Beta release is going to ship with the latest webservices stack too. So either wait few days for the new container to be released or deploy the new stack from the tagged jbossws-cxf sources and get back to us with any feedback :-) Some notes on migration from previous versions of JBossWS are also being added here.
We do plan to reach 5.0.0.Final by the time WildFly 9 will reach Final too.