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.
Note: This tip works properly only with a Metro 2.1 build or higher
As part of the mavenization, project migration and consolidation efforts mentioned in my previous update on Metro 2.1 related changes we have also looked into the ways how we can improve the identification of Metro bits used by our users. We are still not completely done with the solution (e.g. I would like to see some convenient command line script or such available to our users) yet at least the current Metro identification String provides much more relevant information compared to the past.
So how can you find out what Metro version are you running on? The identification string is located in both OSGi-fied as well as non OSGi-fied version of the Metro runtime jar, i.e. webservices-osgi.jar or webservices-rt.jar respectively and it is stored in the com/sun/xml/ws/util/version.properties file under the build-version key. To print the value of this property, you can use following (bash) command:
$ unzip -p webservices-osgi.jar com/sun/xml/ws/util/version.properties | grep build-version |
or
$ unzip -p webservices-rt.jar com/sun/xml/ws/util/version.properties | grep build-version |
You should see an output similar to this one:
build-version=Metro/2.1-b25 (trunk-6664; 2010-12-31T11:31:15+0000) JAXWS-RI/2.2.3-promoted-b06 JAXWS/2.2
What does this value mean? It may be obvious that this artifact belongs to
Thus if you want to see what version of Metro is bundled in the build of GlassFish 3.1 (or later) that you are using, just cd <gf-install>/glassfish/modules directory and run the OSGi version of the above-mentioned command. I shall also note that this information is also available in all HTTP based client requests as a value of the HTTP User-Agent request message header and as such will be visible in any HTTP traffic monitoring tool or in Metro HTTP message dumps.
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:
AS_HOME environment variable to point to your GlassFish installation directory$AS_HOME/bin/asadmin start-domainMETRO_HOME environment variable to point to the unzipped metro/ directorycustom-tubes sample directory, e.g. cd $METRO_HOME/samples/custom-tubesReadme.txt file located in the custom-tubes sample directory to build and run the sample