Friday, June 26, 2015

Migrating sources to GitHub

I've been asked multiple times why the JBossWS project sources were still hosted on a Subversion repository. I've also had to put up with the complaints on time-consuming checkouts and even a bit of mockery from someone for not having migrated to Git yet...
Anyway, last week I had some quiet days, got the inspiration and started the migration... so now the JBossWS sources are eventually hosted on GitHub :-)

I've started by creating a jbossws organization on GitHub. Since the JBossWS project is actually a collection of multiple components each having its own lifecycle, I decided to create a repository for each of them into the organization.
A proper migration requires importing the whole svn repository history, of course; the easiest approach to achieve that is to rely on the GitHub importer. The tool worked fine for me with the smallest repositories (for instance the jbossws-api and jbossws-spi ones), even if it took something like 2 hours for each import (but it's nice that you can let it run on background and be notified by email when the process is completed). Unfortunately, when letting the tool process big sections of the JBossWS Subversion repository (like the jbossws-cxf stack integration), weird import errors were eventually reported, so I had to figure out another way to perform the import.

The alternative approach that worked is based on git-svn. The first step is to build up a comprehensive author mapping file linking svn commit authors to GitHub users. I used the following bash command:

> svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt

Then I created a local Git repository from the Subversion sources with the following command:

> git svn clone --stdlayout --no-metadata -A authors-transform.txt http://anonsvn.jboss.org/repos/jbossws/stack/cxf /tmp/rep

The process still takes multiple hours and fails if a not-mapped user commit is found, but when it's completed you have a copy of all sources in a local Git repository that is almost ready to push. Almost... as I still had to deal with tags because they're fetched the same as branches by the command above.
I moved to the /tmp/rep directory and started by adding a remote repository link and pushing the master:

> git remote add origin https://github.com/jbossws/jbossws-cxf.git
> git push -u origin master

Then you'd have to manually create all the tags, but that's clearly unpractical if you have hundreds of them, so I googled a bit and ended up using the following two commands to generate the actual commands for pushing branches and tags respectively to the remote repository:

> printf "git push origin "; git show-ref | grep refs/remotes | grep -v '@' | grep -v remotes/tags | perl -ne 'print "refs/remotes/$1:refs/heads/$1 " if m!refs/remotes/(.*)!'; echo

> printf "git push origin "; git show-ref | grep refs/remotes/tags | grep -v '@' | perl -ne 'print "refs/remotes/tags/$1:refs/tags/$1 " if m!refs/remotes/tags/(.*)!'; echo

I only had to clean up the output of the first command a bit as the trunk branch was clearly not to be pushed (it's the master pushed previously) and I actually did not want to push some stale branches.
After having iterated the process above for all JBossWS components that failed the automatic import process, I finally had all the sources there at GitHub.

The final steps were to disable the issue tracker & wiki on GitHub (we already use JIRA and have an equivalent to the wiki at jboss.org) and to invite proper users to join the Owner group for the organization as well as other specific groups that were needed.

A day was later spent on updating the continuous integration build environment and the project home page to point to the new repositories... but that's not that interesting to be described in details here ;-)

Enjoy the new repos, fork JBossWS and feel free to submit pull requests with your patches!

Monday, April 27, 2015

JBossWS 5.0.0.Final is available!

I'm happy to announce that JBossWS 5.0.0.Final is out!
The release comes with lots of new features and bug fixes. To get an idea of the new functionalities you can have a look at previous posts here, here and here.
Besides for the upgrade to Apache CXF 3 series, which brings a lot of new and interesting features, this release mainly focuses on providing simplified configurations options to the user. In particular:
With the above items (as well as other new functionalities) covering most of the scenarios in which users would have needed Spring based descriptors, the JBossWS integration with Spring is now declared deprecated.

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

The documentation is included in the release (together with the sample testsuite) and is also available at https://docs.jboss.org/jbossws/5.0.0.Final/ in its latest version.
The supported target containers for this release are WildFly 8.0.0.Final, WildFly 8.1.0.Final and WildFly 8.2.0.Final. The current WildFly master has also been updated to the new WS components so that future WildFly releases will come with it.
Have fun :-)

Tuesday, March 24, 2015

Moving towards JBossWS 5...

Even if I've been silent here lately, my team is actively working on JBossWS 5 and we're getting closer to the first non-Beta release.

The first Beta release (JBossWS 5.0.0.Beta1) was tagged in September last year; it brought Apache CXF 3 series in JBossWS / WildFly and eventually dropped JAX-RPC support ;-)

JBossWS 5.0.0.Beta2 was tagged a couple of months later and featured improvements in the pre-defined client/endpoint configuration area and the options for declaring Apache CXF interceptors through simple configuration properties.

The latest Beta release so far, JBossWS 5.0.0.Beta3, has been tagged and integrated in current WildFly master last month; the most notable change in it is the completely new build and testsuite framework, which now fully relies on Arquillian and ShrinkWrap for WS endpoints testing.

More interesting additions, in the direction of enabling configuring Apache CXF proprietary features without recurring to Spring descriptors, have already been implemented and are coming soon.

Now, you're welcome to go, checkout JBossWS 5.0.0.Beta3 tag and play with it. Or you can simply hack on the latest WildFly master. (also note that WildFly 9 Beta1 is being released very soon!)
Alternatively, you could also play with another recent WS release, the 1.1.0.Beta1 version of the our jaxws-codefirst Maven Archetype, which has just been moved to rely on JBossWS 5 Beta artifacts. You can read about it in a previous post of mine, but it basically boils down to simply using the following command line to kick start a WS project in few seconds:
mvn archetype:generate -Dfilter=org.jboss.ws.plugins.archetypes:

That's all for now, stay tuned, JBossWS 5 is coming... :-)

Tuesday, September 23, 2014

A book on JAX-WS in WildFly and more...

It was last winter when I was offered to author a book on the Web Services stack provided by JBossWS / Apache CXF in WildFly. I eventually took up the challenge and invested part my spare time on writing the book.
To be honest, what really inspired me was the chance of finally being able to write down from scratch how I believe a user should approach the Web Services world and move on from the theory to real world usage scenarios.
As a matter of fact, throughout the years I spent contributing and leading the JBossWS project, I've often had to deal with users picking up concepts and code snippets from books here and there and then asking why they were not achieving what they expected in JBoss AS / WildFly. This opportunity looked like a way to eventually say "look, if you really don't want to read and understand the project documentation, here is a book that likely has all you need and nothing more" ;-)
The goal was probably a bit too ambitious, nevertheless I believe the result of my effort is definitely good.
So, if you want to get your hands on my JAX-WS book, it's currently available in electronic edition at itBuzzpress.com and on Amazon. Printed edition coming soon.

Tuesday, September 16, 2014

How to kick start a WS project in few seconds

One of the goals I committed to when I joined the JBoss Web Services project back in 2007 was to improve the JBossWS tooling offer and possibly make the users' life easier when they have to deal with WS technologies.
Some of the solutions we developed in this area during the past years are now surpassed, others are still here and being used (as an example, think about the Wise project, which gets very limited attention from us due to lack of time, but currently powers the Web Service Tester within JBoss Tools, just to say).
In the last years Maven has been adopted as the de-facto standard solution for building projects; as a consequence, the JBossWS team made available a couple of Maven plugins for running its JAX-WS tools (wsconsume and wsprovide). As part of a customer project build it is hence possible to automatically generate a JAX-WS client or Service Endpoint Interface from a given WSDL contract and viceversa.
In February last year, with the aim of further clarifying how the plugins could be leveraged in final user projects, I wrote a post on the forum describing an example of the above mentioned Maven plugins.
The next step was to simplify the sample project creation and that's what has been eventually addressed. The JBossWS project now features a custom Maven Archetype, basically a WS-enabled project template toolkit.
Whenever a user needs to start a new project aiming at providing and/or consuming a JAX-WS endpoint, the new jaxws-codefirst archetype allows creating a starting project (including working build and sample helloworld client and endpoint) in few seconds. It's simply a matter of issuing a command and replying to simple questions on the desired artifact and group ids for the project being generated:

mvn archetype:generate -Dfilter=org.jboss.ws.plugins.archetypes:

The generated project includes:
  • a sample HelloWorld code-first POJO endpoint
  • an integration test that gets the WSDL contract for the above service, builds up a client and invokes the endpoint
  • a pom.xml for creating a war archive; the project has proper WS component dependencies and uses both wsprovide and wsconsume maven plugins for generating the contract for the code-first endpoint and then generating the client stubs for such contract
  • a plugin for deploying the archive on WildFly.
The project is built and tested by simply running:

mvn wildfly:deploy
mvn integration-test

The build processes the various plugins and calls into the JBossWS tools to generate all the required classes for building the deployment archive and client. The user can test the sample, have a look at the project structure and then either trash the sample endpoint and testcase and replace them with his own components, or modify them step-by-step to achieve what he needs. No need to start from scratch anymore :-)
A 1.0.0.Beta1 version of the archetype is currently available; it relies on JBossWS 4.2.3.Final and is out there for early testers. I've been fixing few bugs on it recently and the plan is to release a new version, based on JBossWS 5, together with the next release of the webservices stack. So give it a try and send us your feedback; we'll try to fix any issue before the release.

Friday, September 5, 2014

JBossWS 4.3.1.Final is available

While working on the JBossWS 5 major changes, the WS team has been fixing a bunch of bugs that were reported on the 4.3.0.Final release.
As it's now more then 5 months since last Final release, we've pushed a couple of Apache CXF upgrades (2.7.11 and 2.7.12) into the 4.3.x maintenance branch and released a new micro version, JBossWS 4.3.1.Final.

The binary and source distributions are available for download and the latest Maven artifacts have been added to the repository.
The supported target containers for this release are JBoss AS 7.2.0.Final, WildFly 8.0.0.Final and WildFly 8.1.0.Final.

Any feedback, just let us know :-)

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.