GlassFish 3.1 has been just released. It contains many new features and stability improvements (more details about the release are here) as well as all the new Metro 2.1 release. You can find out more about Metro 2.1 features from my earlier Metro 2.1 preview post. Fabian Ritzmann also wrote a nice Metro 2.1 feature summary in his recent post.
I have just added a new
custom-tubes sample to the Metro/WSIT sample collection. It is based on one of my previous posts on intercepting web service calls in Metro using custom tubes. I have tested the sample with GlassFish 3.1-b40 and latest Metro 2.1 standalone bundle used on the client side.
To run the sample you need to follow these steps:
- Download and install most recent build of GlassFish 3.1 from the following location: http://dlc.sun.com.edgesuite.net/glassfish/3.1/promoted/
- Don’t forget to set the
AS_HOMEenvironment variable to point to your GlassFish installation directory
- Don’t forget to set the
- Start GlassFish, e.g.
- Download most recent Metro 2.1 standalone bundle from the Metro maven repository: http://download.java.net/maven/2/org/glassfish/metro/metro-standalone/
- Unzip the downloaded Metro 2.1 standalone bundle and set
METRO_HOMEenvironment variable to point to the unzipped
- Change to the
custom-tubessample directory, e.g.
- Follow the
Readme.txtfile located in the
custom-tubessample directory to build and run the sample
… since I wrote my last blog. And it’s not because I would not have anything to write about, but because I was rather busy working on a new release of Metro. The new Metro 2.1 is currently in the in the late pre-release state and we are preparing to release soon.
Many things happened in the Metro project since the last Metro 2.0.1 release. Perhaps most notable are the two of them:
- Metro mavenization
- Metro project migration to a new Kenai infrastructure
Metro project migration
Although both changes do have a visible impact on the Metro users, the latter one is perhaps more apparent. The first change a user would notice is the new project URL. The Metro project URL has changed from https://metro.dev.java.net/ to http://metro.java.net/. It means that you no longer need to use HTTPS to access public project web pages and the content loads faster. Also, with the new infrastructure, it is possible to use “sticky” login, so that your login information is remembered and you are not required to log in again when you access a restricted java.net page e.g. the next day. For someone like me who works with java.net on a daily basis this is a huge improvement. Similar URI related change applies to Metro mailing lists. Please consult the new Metro mailing list addresses here: http://java.net/projects/metro/lists
Another very important change in the Metro project caused by the migration to the new infrastructure is a decision to abandon nowadays somewhat obsolete CVS version control system and switch to SVN instead. Thus the new way how to checkout Metro/WSIT sources is:
svn checkout https://svn.java.net/svn/wsit~svn/trunk/wsit
For further information about working with Metro sources, please consult the Metro contributors page.
I shall perhaps mention that we also considered switching to a DVCS (e.g. Mercurial, GIT) but then decided to take smaller steps at a time. We may still revisit this decision in the future based on the feedback we receive from users. Should you have an opinion on this (or any other Metro related) topic that you want to share with us, please send an email to the Metro users mailing list.
The last very important project migration related change that comes to my mind is the new issue tracker that we use for projects running on the new java.net infrastructure – JIRA. For more information how to access Metro related issues, please see our Metro Issue Trackers page. Since JIRA has lots of capabilities, in the future Metro releases we are considering using JIRA not only as an issue tracker but also as the main feature & task manager.
Along with the project migration to the new infrastructure, Metro mavenization is second biggest non-functional change. Over the time we have been receiving numerous user requests for a better support of Maven-based development model. Also internally, we were constantly fighting with introduction of a more rigorous release management process and the maintenance of ever larger set of dependencies and their respective versions. And since our main delivery vehicle which Metro integrates into — GlassFish — has also switched to Maven a while ago, it was only natural to follow the same direction. And so we did…
As of today, all the main Metro bundle build scripts have been mavenized. Additionally, workspace of the WSIT project has been thoroughly restructured and modularized basing the module structure mainly on the code relationship to different WS-* domains. It was not an easy task and it involved a lot of refactoring as well as introduction of several inter-module API layers to allow for cleaner separation of the inter-module dependencies. In the future, the idea is to complete the Metro project mavenization by mavenizing also the JAX-WS RI workspace, which is the last (standalone) piece that is yet to be mavenized. From the user perspective not having JAX-WS RI project mavenized is not a big deal though, because JAX-WS RI is internally consumed by Metro/WSIT and as such we were forced to fix all the dependency related issues in the Maven artifacts produced by non-Maven JAX-WS RI build process.
To learn more about how to work with the mavenized Metro binaries, kindly consult the recently updated Maven section of the Metro User Guide.
Few notes on new Metro features
Metro 2.1, when released, will be just a minor update over Metro 2.0 so one should not expect any radical changes. Still, when it comes to functionality, apart from the bug fixes and small improvements, there are two topics I would like to briefly mention here.
First of all, after (5 or so) years we are finally officially introducing full-featured support of clustered environments. This feature currently comes with soon to be released GlassFish 3.1. While Metro high availability and failover support does not directly depend on the GlassFish 3.1 HA infrastructure but rather on a thin layer of a platform-independent HA API, in Metro 2.1 release we did not spend any effort in testing or integration of our HA support with other containers. However when it comes to GlassFish 3.1, we have created a very comprehensive HA test suite to verify that Metro HA would work well within GlassFish.
Another big thing feature-wise in Metro 2.1 is a complete replacement of the WS-AtomicTransactions/Coordination (or in short WS-TX) implementation code. The new code is essentially a WS-TX implementation from the Oracle WebLogic Server retrofitted to use the specific Metro and GlassFish run-time APIs where necessary. This new implementation introduces support for standardized versions of the WS-TX specifications in Metro. At the same time, unfortunately, this is a breaking change in the Metro WS-TX implementation to certain extent (particularly in the from-Java EJB WS scenarios) as EJB-based web service endpoints annotated with just the standard JavaEE @TransactionAttribute annotation will not have the WS-TX support enabled by default as was the case with earlier Metro releases. Instead, a new Metro-specific annotation (which is yet to be documented in the Metro User Guide) was introduced to enable WS-TX support for the annotation-based EJB endpoints. We have decided to introduce a breaking change in this case since the old solution has issues with mapping between WS-AT policy expressions and EJB @TransactionAttribute annotation values as well as it seems to complicate CTS testing. Yet, the main message for Metro users is that after quite a long break (caused mainly by the resourcing constraints) we have made a major improvement in the area of WS-TX support in Metro and we are finally on par with the latest WS-TX standards.