Controlling Apache CXF Bus creation for JAXWS clients

JBossWS 4.2.2.Final has just been released and installed in current WildFly master.
The new version comes with multiple bug fixes as well as a relevant new feature for controlling the Apache CXF Bus creation whenever JAXWS clients are built.

Basing the JAXWS functionalities of JBoss AS / WildFly on Apache CXF opened up interesting integration topics, one of them being when to create new CXF Bus instances and when / how to share them in the container. With the latest JBossWS integration release, the strategy for selecting/creating Bus instances to serve (in-container) JAXWS client can be chosen by the final user. This allows better control and can also be used for performance tuning. You can read more about the new feature in the documentation.

The release also comes with upgrades to Apache CXF 2.7.7 and Apache Santuario 1.6.12.
It's now time for you to download JBossWS 4.2.2.Final, install it and give it try! Feedback is welcome as usual!

The supported target containers for this release are JBoss AS 7.1.2.Final, JBoss AS 7.1.3.Final and JBoss AS 7.2.0.Final. Of course, next releases of WildFly are also going to include the new WS components.

JBossWS 4.2.0.Final is available!

I'm happy to announce that JBossWS 4.2.0.Final is out!
The release comes with lots of new features and bug fixes. To get an idea of the most relevant new functionalities you can have a look at previous posts here, here and here.
Besides for the mentioned new features, the new version of JBossWS brings the latest and greatest Apache CXF / WSS4J and Santuario versions into WildFly, whose next release will include the whole new set of ws libraries.

It's now time for you to download JBossWS 4.2.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.2.Final, JBoss AS 7.1.3.Final and JBoss AS 7.2.0.Final. The current WildFly master is also being updated to the new WS components so that future WildFly releases will come with it.

Have fun :-)

JBossWS 4.2.0.CR1 and the WS-Policy sets

Another WildFly release has just been announced... and it comes with the first 4.2.0 candidate release of JBossWS!
The latest JBossWS release comes with some bug fixes over the former Beta build as well as with the last  new feature we planned for addition in 4.2.0, that is additional WS-Policy functionalities for code-first development.
I've just written some documentation, but let me summarize the new features here: some users noticed that writing policy assertions for endpoint wsdl contracts is usually quite difficult and often represents an obstacle to quick development of ws-policy enabled endpoints prototypes.
So we basically decided to provide means for users to choose desired policy assertions among a list of pre-defined groups serving well known needs / scenarios. The result is a custom @PolicySets annotation to list groups of policy assertions; those will be automatically attached to the proper elements in the wsdl contract that is generated at deployment time and the ws stack will behave accordingly at runtime.
The JBossWS 4.2.0.CR1 artifacts come with some initial sets, more are to be added before going final (the feature is implemented, it's just a matter of deciding which set/combination of policies to grant a label). So this is yet another example where feedback is welcome... if you have suggestions for the pre-defined set to add, just post on the JBoss forum!

You can try JBossWS 4.2.0.CR1 either consuming it from the recent WildFly 8.0.0.Alpha2 or by pulling the artifacts from the Maven repository.
Enjoy!

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 :-)