HTTP/1.1 201 Created Location: http://marek.potociar.net/tags/jersey Cache-Control: public Content-Type: text/plain Date: Fri, 28 Jan 2011 22:05:35 GMT Content-Length: 930 Note: This entry is inspired in format by a recent entry on the Paul's Sandoz blog (http://blogs.sun.com/sandoz/entry/301_moved_permanently). After about 5 years of working almost exclusively on the Metro project I wanted to change my focus and explore other areas. And so once Metro 2.1 is released I will start switching my focus more on the Jersey project as a new addition to the Jersey team. As for the Metro project, I will still remain involved to some extent at least for the time being. My new responsibilities on the Jersey project will mainly evolve around Jersey 2.0 implementation as well as helping Roberto with the JAX-RS 2.0 (JSR-339) specification work. I am really excited to start getting involved with the Jersey project and I am looking forward to the new challenges. As one of the first things, I am creating a new tag I will be using for REST/Jersey related posts: http://marek.potociar.net/tags/jersey
… 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.