Just few hours before the holiday break and here we are with the last releases of the year!
First of all, WildFly 10.0.0.CR5 has been released and will soon turn into Final assuming no major flaw is reported. You can read more on the release at wildfly.org!
Speaking of web services, yesterday I've tagged the second micro release of JBossWS 5.1.x series and today you can download it from jbossws.jboss.org. You might have noticed that we've released two bug fix versions this month: JBossWS 5.1.1.Final was mainly a bug fix release (but of course we also moved to the most recent Apache CXF version), while JBossWS 5.1.2.Final is basically a performance improvement release, cut just in time to include it as a last minute change in WildFly 10 :-)
As usual, have a look at the release notes for a detailed list of changes. The supported target containers for both JBossWS releases are WildFly 9.0.0.Final, 9.0.1.Final and 9.0.2.Final.
The year is almost over, time to relax, give the last WildFly 10 CR a try and then get back fully recharged in 2016 to play with WildFly 10 Final :-)
Greetings!
Wednesday, December 23, 2015
Wednesday, September 2, 2015
JBossWS 5.1.0.Final is available!
One month after the beta release, JBossWS 5.1.0 is eventually final!
This time, we have gone for a time-boxed release approach and limited the number of new features on top of previous release. The reason is that we really wanted the upcoming WildFly 10 to include the latest and greatest WS components. As a matter of fact, JBossWS 5.1.0 brings Apache CXF 3.1 series into the WildFly container; the latest Apache CXF versions, in turn, come with few performance improvements that we directly contributed to, while working on optimizing the whole WildFly WS stack.
On top of that and besides for a bunch of bug fixes, an interesting new feature has just been added to JBossWS 5.1, which is support for jboss-webservices.xml descriptor in EAR deployment archives. This allows setting a given behaviour of the stack for all sub-deployments included in an EAR archive packaged application, preventing the user from having to specify the same options in multiple jboss-webservices.xml descriptors.
You can have a look at the release notes for a list of the improvements and fixed issues.
JBossWS 5.1.0.Final is available for direct download and on both the JBoss and Maven Central repositories. The release documentation is here.
The supported target containers are WildFly 8.2.1.Final, WildFly 9.0.0.Final and WildFly 9.0.1.Final... and of course WildFly 10.0.0.CR1 and later will be including it by default already.
Enjoy!
This time, we have gone for a time-boxed release approach and limited the number of new features on top of previous release. The reason is that we really wanted the upcoming WildFly 10 to include the latest and greatest WS components. As a matter of fact, JBossWS 5.1.0 brings Apache CXF 3.1 series into the WildFly container; the latest Apache CXF versions, in turn, come with few performance improvements that we directly contributed to, while working on optimizing the whole WildFly WS stack.
On top of that and besides for a bunch of bug fixes, an interesting new feature has just been added to JBossWS 5.1, which is support for jboss-webservices.xml descriptor in EAR deployment archives. This allows setting a given behaviour of the stack for all sub-deployments included in an EAR archive packaged application, preventing the user from having to specify the same options in multiple jboss-webservices.xml descriptors.
You can have a look at the release notes for a list of the improvements and fixed issues.
JBossWS 5.1.0.Final is available for direct download and on both the JBoss and Maven Central repositories. The release documentation is here.
The supported target containers are WildFly 8.2.1.Final, WildFly 9.0.0.Final and WildFly 9.0.1.Final... and of course WildFly 10.0.0.CR1 and later will be including it by default already.
Enjoy!
Thursday, August 6, 2015
JBossWS 5.0.1.Final and 5.1.0.Beta1
It's summer time, time for a break and for taking some rest... not really, as we released two new versions of JBossWS this week :-)
JBossWS 5.0.1.Final is a bug fix release, solving some issues that were found in the first version of the JBossWS 5 series. It also includes Apache CXF (3.0.6) and WSS4J upgrades that come with additional multiple fixes and security improvements. The target containers for JBossWS 5.0.1.Final are WildFly 9.0.0.Final as well as the recently released WildFly 8.2.1.Final and 9.0.1.Final.
JBossWS 5.1.0.Beta1 is the first milestone of the new webservices stack for WildFly 10, instead. While it drops support for Spring integration (jbossws-cxf.xml descriptor, which was not used a lot and causing confusion and problems), it eventually pulls the latest Apache CXF 3.1.x series. Of course, all the fixes in 5.0.1.Final are included in 5.1.0.Beta1 as well.
Additional new features are coming to 5.1.0 in the next months before it goes Final :-)
Summer time... time to get the latest JBossWS releases and give them a try ;-)
Enjoy!
JBossWS 5.0.1.Final is a bug fix release, solving some issues that were found in the first version of the JBossWS 5 series. It also includes Apache CXF (3.0.6) and WSS4J upgrades that come with additional multiple fixes and security improvements. The target containers for JBossWS 5.0.1.Final are WildFly 9.0.0.Final as well as the recently released WildFly 8.2.1.Final and 9.0.1.Final.
JBossWS 5.1.0.Beta1 is the first milestone of the new webservices stack for WildFly 10, instead. While it drops support for Spring integration (jbossws-cxf.xml descriptor, which was not used a lot and causing confusion and problems), it eventually pulls the latest Apache CXF 3.1.x series. Of course, all the fixes in 5.0.1.Final are included in 5.1.0.Beta1 as well.
Additional new features are coming to 5.1.0 in the next months before it goes Final :-)
Summer time... time to get the latest JBossWS releases and give them a try ;-)
Enjoy!
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:
Then I created a local Git repository from the Subversion sources with the following command:
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:
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:
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!
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:
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 :-)
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:
- it makes very easy to have predefined client and endpoint configurations set for user WS client and endpoints; this is achieved by sensible defaults to the configuration names
- it allows declaring Apache CXF interceptors and features using configuration properties
- it allows tuning the default Apache CXF HTTP Conduit, effectively making it possible to control HTTP transport options (like e.g. chunk mode) through system properties.
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:
That's all for now, stay tuned, JBossWS 5 is coming... :-)
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... :-)
Subscribe to:
Posts (Atom)