JBossWS 4.2.0.Beta1 and WS-Discovery support

Just in time for the first release of WildFly, I've cut the first Beta release of JBossWS 4.2 series and had it pulled into the application server.

The latest build includes the additions I provided a preview of in the previous post as well as integration of few new features from Apache CXF. The most notable one is probably the WS-Discovery support, which you can get some preliminary doc on here.
Users can now have ws endpoints from selected deployments be automatically registered in a WS-Discovery service endpoint; that in turn can be queried to locate existing endpoints over the network. Nice, isn't it? :-)

Feel free to give the Beta a try, artifacts are available on the Maven repo as usual. Feedback is welcome, as always!

JBossWS 4.2 feature preview

This blog post is about few additions that are coming with JBossWS 4.2 release which I actually started working on due to some specific Narayana requirements, but ended up using for additional tasks too.

Starting from version 2.1, the JAX-WS API contains the javax.xml.ws.WebServiceFeature abstract class which is used to configure clients, e.g. when getting the port stub. The JAX-WS reference impl, which is also included in the JDK, bundles three implementations of WebServiceFeature for controlling addressing, MTOM and wsdl:extension usage.

As of JBossWS 4.2.0.Alpha1, a custom extension of WebServiceFeature is available, org.jboss.ws.api.configuration.AbstractClientFeature. That offers users and project integrators a way of initializing the client BindingProvider, setting handlers, etc. The JBoss project for distributed webservices transactions, Narayana, actually leveraged this addition to really simplify the way users write clients for WS-AT and WS-BA enabled webservices. Two custom features built on top of AbstractClientFeature let Narayama hide all its context propagation configuration from the user eyes ;-)

Now, as most of you probably know, JBossWS also comes with a notion of predefined client-configuration which can be used to prepare JAX-WS client configuration templates to associate client ports to. Configurations can include properties as well as handlers declaration and are provided either as part of the JBoss AS webservices subsystem configuration (standalone.xml / domain.xml) or as a separate file.
The AbstractClientFeature extension above offered a way for also simplifying a client-configuration setup for a given JAX-WS client; the org.jboss.ws.api.configuration.ClientConfigFeature allows specifying the name of the desired client-configuration as well as the file to read that from (null for reading from the AS model):

Nice, isn't it?
Feel free to try this as well as any other additions on JBossWS trunk, the 4.2.0 final release is coming in the next months. Feedback is welcome!

Maven plugin for JAXWS tools, again!

Back in March 2010 I wrote about our JBossWS Maven plugin for running JAXWS tools (wsconsume and wsprovide). The plugin allows embedding tools' invocation into user Maven projects, so that given a wsdl contract you can e.g. automatically generate stub classes and interfaces for a ws endpoint you want to implement or for an endpoint you want to build a client for.
Yesterday I cut a micro 1.1.1.Final release of the plugin (org.jboss.ws.plugins:maven-jaxws-tools-plugin), which is available on the usual JBoss Maven repository. You're welcome to go and try it.
On that purpose, I've written a small sample project showing how a user project can actually use the wsconsume plugin. It's available on the wiki, have a look and see how easy it's to use it! :-)

WS testing... Wise is back!

Wise is an interesting project with the aim of simplifying webservices invocation. One of the possible usecases it enables is quick testing of WS endpoints without the need of generating and compiling client stubs or directly writing SOAP / XML messages.

I've spent some time lately on this topic and finally cut a new release of Wise including a web gui. This runs of top of JBoss AS 7 and is hence based on JBossWS. Consider having a look, to me it's a convenient tool when it's time to test WS services (especially for business quality acceptance) and you don't want to get your hands dirty with code or xml (or you're not expected to do that, perhaps because you're a business quality engineer ;-) )

Wise Web GUI - Invoking a test endpoint

JAX-WS tools and the Java Compiler API

As of today, Apache CXF is well integrated into JBoss AS 7 and working properly through the JBossWS layer. The application server satisfies the JavaEE 6 requirements (of course including the WS related ones) and most of the Apache CXF specific funtionalities are continuously tested by the JBossWS own testsuite and covered in the application server webservices documentation .

While we do have plans for future new features and contributions, even directly on Apache CXF, we still have very few action items to work on in the pure JBoss AS integration area. Last week I dealt with one of them, which turned out to be quite interesting from a technical point of view, so I thought it's worth to share it here.

It is well known that JBoss AS 7 is built on top of the modules' concept and comes with a fully modular classloader defined by module dependencies and really allowing controlling which classes to load, etc. As part of the move to the new classloading mechanism, we created modules for most of the Java EE apis that we include in the application server, JAX-WS api being one of them. Our own JAX-WS api module comes with a slightly modified version of the vanilla jaxws 2.2 apis, which resolves the javax.xml.ws.spi.Provider into the corresponding JBossWS implementation (defaults to it, unless different configuration is specified using the Service API mechanism). The jaxws api module is then used to define the classloader for any application in the application server, so that whenever JAXWS is required its classes are used and the JBossWS (Apache CXF based) implementation is automatically used under the hood. Besides for the fact that we're easily enforcing usage of our JAX-WS impl this way, the real benefit of such an approach is that we always control the JAX-WS api level (currently 2.2) in use.

As a matter of fact, a mismatch in JAXWS api version is usually a common source of major final user headaches; the reason for that is basically in JDK 6 (well, actually starting from update 4) coming with JAXWS 2.1 api included. Unless the bootclasspath is properly modified by setting the java.endorsed.dirs env to a directory containing the  jaxws 2.2 api jar when starting the virtual machine, 2.1 api classes from the JDK will always be used by default whenever making use of JAX-WS apis. Users will eventually forget about that, make mistakes in setting that, get confused with tools / IDE configuration of that, etc... and not understand what's really happening and why they're getting bunch of errors.

JBoss AS 7 relies on JBoss Modules for modular classloading and does not require any java.endorsed.dirs setup when booting the AS. So far so good :-)

JBossWS (as well as Apache CXF) however provides JAX-WS tools for wsdl-to-java and java-to-wsdl generation; each of them comes with wsconsume.sh/bat and wsprovide.sh/bat scripts to execute on command line. The tools internally rely on Apache CXF corresponding tools, which generate code and compile it. In order for having CXF compile jaxws 2.2 compliant code, we used to need setting the java.endorsed.dirs env in the wsconsume and wsprovide scripts, failing that the code couldn't simply be compiled, because CXF runs javac which would of course get the JAXWS api directly from the JDK.

So, a jira has been created for fixing this, as we do not want to set the java.endorsed.dirs anymore, even for ws tools. How to solve this then?

Fortunately, Apache CXF tools recently moved to direct usage of Java Compiler API to compile sources, instead of forking a process for running javac (forking is still possible, yet not the default behaviour). Starting from JDK 6, the Java Compiler API (JSR-199) offers a powerfull (yet quite complicated) way of creating a compilation task and supplying source files to it for being compiled. Below is an excerpt of the CXF code making use of JSR-199:

The javax.tools.JavaFileManager interface allows for controlling loading of any class involved in the compilation task; it's possible to define and install a custom ForwardingJavaFileManager to override the methods that actually fetch and provide the bytecode for any class.

So, what we ended up in doing here was to define an extension of  ForwardingJavaFileManager that would intercept requests for the JAXWS (and JAXB...) api classes, load the corresponding ones from our JBoss Module classloader, read their bytecode and create proper JavaFileObject instances to return to the JDK compiler. It took a while to write a decent JavaFileManager implementation (also considering I didn't want any JBoss Module specific code in it in JBossWS), but it finally worked and allowed compiling jaxws 2.2 code with JDK6 and no endorsing configuration.

Then, the usual JBossWS open source integration process started, as I had to figure out how to extend Apache CXF in a general way so that I could made my JavaFileManager available deep into the CXF tools code. Once again, the Apache CXF community proved to be really open to extensions and contributions even for really specific stuff like this and the Apache CXF project lead even figured out possible different scenarios that would benefit from my extension. So a CXF jira was created, we discussed design a bit on IRC and I committed my changes on Apache CXF and JBossWS.

A new Apache CXF release is coming out very soon and hopefully by the end of next week I'll be able to include it in JBoss AS upstream and fix the wsconsume/wsprovide command line scripts, cool!

This is what integration really means to me :-)

JBossWS 4.1.0.Final has been released!

It's been a long ride, but today I can finally announce that JBossWS 4.1.0.Final is out!
This release is the result of 6+ months of work on integrating most of the latest Apache CXF additions as well as providing new options and mechanisms for better stack configuration on JBoss AS.
On June I introduced some of 4.1 news just after having released the first Beta; below is a brief summary of what has finally been included in Final.

Apache CXF 2.6

We've moved the integration to Apache CXF 2.6.3, which comes with relevant improvements and new features in multiple areas, including WS-Security, WS-MetadataExchange and WS-ReliableMessaging.

WS-Security work

First of all, I finally had chance to go through most of the WS-Trust recent improvements in CXF and verify the integration on JBoss AS 7. In particular, I tried some of the most common WS-Trust scenarios and verified it's possible to deploy and successfully use a Security Token Service (STS) based on either the Apache CXF STS implementation or the PicketLink STS one. A sample application (whose sources are also included in the binary release distribution) is covered in the documentation.
Besides WS-Trust, I've also enriched the JBossWS testsuite to verify most of the WS-SecurityPolicy Examples 1.0 scenarios (already implemented in Apache CXF testsuite) are also easily implemented on top of JBoss AS leveraging the JBossWS integration; once again, this shows how many (amazing) security policy functionatities Apache CXF brings into our application server.
Finally, speaking of security, it's important to mention that this release (including transitive dependencies), comes with few security vulnerabilities fixes in multiple areas, so you should definitely upgrade.

Configuration improvements

The jboss-webservices.xml descriptor has been enhanced to allow passing in properties for controlling some of the Apache CXF internals potentially affecting runtime integration, e.g. the queue depth of the asynchronous (@OneWay) work queue, or the server side preferred policy alternative selector.
Besides that, we've completed the work around the predefined client/endpoint configurations mechanism that was started in 4.0.x series. This comes with a great flexibility and enables interesting user scenarios; you can e.g. define a common handler to be plugged in any handler chain of clients / endpoints of a given group (even spanning multiple deployments), or enable schema validation on messages exchanged by those clients / enpoints... all without touching the user deployments, but by simply editing the referred configuration in the JBoss domain (e.g. in standalone.xml) or in a file descriptor.

Other improvements

There's of course much more in this release, including:

• verified IPv6 support
• rewritten JAX-WS POJO invocation mechanism, to enable CDI injections in WS endpoints in the next future
• WSProvide option for specifying soap:address location to use in generated wsdl
• improved testsuite (execution time, memory footprint, code & feature coverage)
• a lot of bug fixes

Please have a look at the release notes for the complete list of changes.

Finally a note on the JBossWS multiple stack integration efforts; as previously announced JBossWS-Native reached EOL and is not being released as full stack to the community anymore. Its sub-components have been slimmed down to the minimum required for still supporting JAX-RPC and it is included as support library for JBossWS-CXF into JBoss AS.

It's now time for you to download JBossWS 4.1.0.Final, install and give it a try! Feedback is welcome as usual!

The documentation is included in the release distribution (together with the sample testsuite) and is also available at https://docs.jboss.org/author/display/JBWS in its latest version (might include not-released-yet features in future).

The supported target containers for this release are JBoss AS 7.1.0.Final, JBoss AS 7.1.1.Final and JBoss AS 7.1.2.Final. The current AS master is also being updated to the new WS components so that future AS releases will come with it.

Have fun :-)

Looking at the next future... JBossWS 4.1

With the summer coming, it's now few months since the last 4.0.x release of JBossWS. While working on finalizing JBoss Enterprise Application Platform 6, the WS team here has started the JBossWS 4.1 dev cycle.
Last week, the first Beta version has been released, covering a bunch of new features on topics we identified during the last year and which could not fit the former 4.0 cycle. Here is a list of the most noteworthy ones in 4.1.0.Beta1:

• Upgrade to Apache CXF 2.6.1: this comes with many bug fixes and new features from Apache CXF side, like eg. WS-ReliableMessaging 1.1 support, lots of improvements in WS-Security area, WS-MetadataExchange (Aug 2006 spec) support, ...
• Apache CXF Security Token Service (STS) integration: one of most active area in CXF development lately, which is now verified to work properly under the JBoss WS 4.1 / JBoss AS 7.1 integration
• Configurability improvements: the jboss-webservices.xml descriptor has been enhanced to allow passing in properties for controlling some of the Apache CXF internals potentially affecting runtime integration, e.g. the queue depth of the asynchronous (@OneWay) work queue, or the server side preferred policy alternative selector
• IPv6 support: with the world finally really moving to IPv6, we've gone through yet another IPv6 testing phase and are currently able to successfully run the whole JBossWS testsuite against JBoss AS 7.1 using IPv6
• JBossWS-Native cleanup: after years of coexistence of multiple JBossWS integration stacks, the time for putting the old JBossWS-Native to EOL has come. As a consequence, we've slimmed down its sub-components to the minimum required for still supporting JAX-RPC and be included as support library for JBossWS-CXF into JBoss AS. Long life to the JBossWS integration with Apache CXF!

This is a beta, basically because we've further new features to add and many tests / verification still to run, so any contribution and feedback from the community is more then welcome, as usual. This time, however, we also come with two development-related only changes that are likely to ease testing:

• Parallel / concurrent testsuite run: the JBossWS testsuite has been revisited and multiple tests are now executed at the same time. No need for any change on user side, a couple of minutes less for a full run and few bugs isolated thanks for the new testing conditions ;-)
• Reduced testsuite memory footprint: I've been profiling the testsuite (client side) and optimized it a bit, so that you can have concurrent runs even if you don't have tons of RAM ;-)

That's all for now. JBossWS 4.1.0.Beta1 has been installed on the current JBoss AS 7.2 master and the artifacts are available on the Maven repository. The release notes are here.

Expect more to come during the summer!