Monday Feb 28, 2011

Metro 2.1 in GlassFish 3.1

Today's release of GlassFish 3.1 comes with Metro 2.1 as the SOAP Web Services provider. Here is a roundup of the new features Metro 2.1 adds over previous releases. See the Metro release notes for more details.

  • Support for high availability for stateful web services, reliable messaging, security nonce manager and secure conversation.
  • Completely new implementation supporting WS-Coordination and WS-AtomicTransaction 1.0, 1.1 and 1.2.
  • Support for WS-SecurityPolicy 1.3.
  • Initial support for WS-Policy alternatives in the WS-Security domain.
  • Support for JAAS KeyStoreLoginModule.
  • Support for standard error handling in WS-Trust / WS-SecureConversation.
  • Time skew for WS-Trust and WS-SecureConversation token lifetime.
  • JAX-WS RI 2.2.3
  • JAXB 2.2.3-1

Friday Nov 12, 2010

Metro projects migration to Kenai infrastructure

The migration of the Metro projects to the new Kenai infrastructure is (mostly) done by now. Unfortunately it took a lot longer than expected and the channels we usually use to notify our users like the mailing lists and forum were down during that time.

Please note that the project URLs were all changed. The old projects were under The new projects are under Getting rid of the https URL should result in web pages that load much faster. The old URL will forward to the new one but that only works for the base URL. Any links directly to e.g. the user guide need to be updated.

We are still working on getting the content and links on all Metro web sites updated as well as our build jobs. Those projects that used to use CVS were converted to Subversion. JAX-WS is right now still using CVS because of failures with the conversion.

Wednesday Nov 03, 2010

Metro projects migration to Kenai infrastructure delayed

The migration of the Metro projects to the Kenai infrastructure is still in progress. As it looks right now, it is possible that the migration will not be complete until November 9. Until then, unfortunately, the mailing lists, forums and repositories remain locked. It seems that the transfer of data from the current hoster to the new infrastructure takes far more time than anticipated.

Thursday Oct 28, 2010

Metro projects migrating to Kenai infrastructure

Here is a slightly adapted version of the notice that went to the mailing lists:

The projects listed below, will begin migration to Kenai infrastructure, midnight, Wed. Oct. 27th. During this period these projects will be locked. Project content will be read-only until the migration process is completed. E-Mail to the migrating project lists will not be delivered. We anticipate this process taking through Tuesday Nov. 2.

  • Metro
    • jax-ws
      • JAX-WS commons (jax-ws-commons)
      • Sourcecode for JAX-WS (jax-ws-sources)
      • JAX-WS RI Unit Test (jaxwsunit)
      • JAX-WS test harness (ws-test-harness)
    • mimepull
    • ws-policy (policy)
    • wsit

This is the first wave of GlassFish project migrations to the Kenai suite. If all goes to plan, the second phase will be scheduled for early in the second half of November.

During this transition period, we will provide updated status at the glassfish-migration wiki at kenai: You may also send an e-mail request to migration-help-AT-glassfish-migration.kenai-DOT-com.

During this transition, we encourage you to begin to familiarize yourself with the Kenai tools. We have started documents which should help with this:

These will be updated as the process evolves so, please bookmark them, or use the RSS feed to monitor for updates. Starting Tuesday Nov. 2, user transition notices will be e-mailed to all users. You will need to follow the directions to enable your new account. There are several hundred thousand notices which will be e-mailed so please be patient with this process.  

Thursday Sep 16, 2010

Metro sessions at JavaOne 2010

Here is a list of JavaOne sessions that - to my knowledge - relate to Metro in some form. I will myself be hosting BOF S314122 "Metro Web Services Configuration Management for the Enterprise".
Session ID Title Session Type Duration Schedule Availability
(at the time of writing)
S313916 JAX-WS.Next: Future Directions and Community Input BOF 45 min. Monday, September 20, 7:30PM
Moscone South, Rm 308
S314122 Metro Web Services Configuration Management for the Enterprise BOF 45 min. Monday, September 20, 9:30PM
Moscone South, Rm 301
S314715 Nonblocking Lightweight Web Services with Grizzly BOF 45 min. Tuesday, September 21, 7:00PM
Hilton San Francisco, Yosemite B
S314285 Using OAuth with RESTful Web Services Hands-on Lab 120 min. Wednesday, September 22, 10:00AM
Hilton San Francisco, Plaza B
S314098 Securing Web Services Hands-on Lab 120 min. Wednesday, September 22, 12:30PM
Hilton San Francisco, Plaza A
S314256 Securing RESTful Web Services in Java Conference Session 60 min. Wednesday, September 22, 1:00PM
Parc 55, Market Street
S314397 SOAP and REST Web Service Use Cases, Interoperability, and Programming Models Conference Session 60 min. Wednesday, September 22, 4:45PM
Parc 55, Market Street
S313277 Beginning with the Java EE 6 Platform Hands-on Lab 120 min. Thursday, September 23, 11:00AM
Hilton San Francisco, Plaza A
S314397 SOAP and REST Web Service Use Cases, Interoperability, and Programming Models Conference Session 60 min. Thursday, September 23, 11:00AM
Parc 55, Market Street

Thursday Dec 10, 2009

Runtime Configuration Management in Metro 2.0

Today's release of Metro 2.0 comes with a novel feature that we call Configuration Management (WS-CM). It allows to reconfigure a running JAX-WS web service instance without losing any messages. The web service does not have to be redeployed or restarted. All configuration changes are persisted across application redeployments and server restarts.

Metro provides an easy to use management interface based on JMX to reconfigure managed web service instances. Any WS-Policy configuration may be changed through that interface. That means you can make extensive changes to your web service's security, transaction, messaging, and many more settings.

You can find the full documentation in the Metro guide in the chapter "Monitoring and Management". WS-CM works in all containers supported by Metro 2.0, i.e. Tomcat, GlassFish V2 and GlassFish V3, released today.

Tags: Web Services, Project Metro, JAX-WS, GlassFish V3

Tuesday Dec 08, 2009

Named parameters in Java

I was recently writing some Java factory code that would have benefited from named parameters. Java unfortunately does not support named parameters. I searched around the web for some solutions that could provide a work-around but did not find anything.

I was trying to solve a problem that seems common when you are implementing a factory. Imagine a factory that creates objects but does not or should not know what parameters these objects take for initialization. The factory interface might look like this in Java:

public interface Factory {
    public Result create(Object... parameters);

The above has two issues. Object... (and its equivalent Object[]) does not provide any type safety. And parameters depend on the position in the array, which is very error-prone. Code using the above would look like this:

Type1 parameter1 = (Type1)parameters[0];
Type2 parameter2 = (Type2)parameters[1]

You might ask yourself why I do not just use something like "String... parameters" for type safety? That is fine as long as you can be sure that all your objects are only initialized with Strings and no parameters of any other type that is not a subtype of String. And you still need to be very careful that all parameters are always passed in the correct order.

The obvious improvement over using an array or a list to pass arbitrary parameters is the use of a Map. If you use parameter names as map keys and the actual parameter as the map values, you are somewhat closer to real named parameters already. This is how the factory interface could look like then:

public interface Factory {
    public Result create(Map<String, Object> parameters);

The drawback with the above is that any code using the parameters must cast from Object to the actual type like this:

Type1 parameter1 = (Type1)parameters.get("parameter name 1");
Type2 parameter2 = (Type2)parameters.get("parameter name 2");

When we reviewed this code, someone suggested a solution using Generics instead:

public interface Factory {
    public <T> Result create(Map<String, T> parameters);

Unfortunately, that approach does not work because it forces you to use the same type T for all parameters. In other words, it is the Generics equivalent to the "String... parameters" approach discussed earlier.

We can take the Map approach one step further if we introduce one additional layer of indirection. Instead of using a Map with the same type T for all values, we can implement a wrapper that allows to use an individual type for each parameter:

public class NamedParameters {

    private final HashMap<String, Object> nameToInstance = new HashMap<String, Object>();

     \* Add parameter with the given name.
     \* @param <T> The type of the parameter.
     \* @param name The name of the parameter.
     \* @param parameter The parameter.
     \* @return This instance of NamedParameters (so that you can chain multiple put calls).
    public <T> NamedParameters put(String name, T parameter) {
        this.nameToInstance.put(name, parameter);
        return this;

     \* Get parameter with the given name and type. Returns null if a parameter
     \* with the name exists but has a different type.
     \* @param <T> The type of the parameter.
     \* @param name The name of the parameter.
     \* @return The parameter with the given name or null.
    public <T> T get(String name) {
        try {
            return (T) this.nameToInstance.get(name);
        } catch (ClassCastException e) {
            return null;


The factory would now look like this:

public interface Factory {
    public Result create(NamedParameters parameters);

And you would use it like this:

Type1 parameter1 = parameters.get("parameter name 1");
Type2 parameter2 = parameters.get("parameter name 2");

You might have noticed the @SuppressWarnings("unchecked") annotation on the NamedParameters get method. There may be ways to avoid using this annotation but ultimately you cannot hide that Java type erasure strikes and the type information of the stored value object is lost. That is why we explicitly have to cast and return a null value if the types do not match. This example demonstrates the issue:

NamedParameters parameters = (new NamedParameters()).put("parameter name 1", "text")
                             .put("parameter name 2", new Integer(5));
String parameter1 = parameters.get("parameter name 1");
// parameter2 will be null:
Boolean parameter2 = parameters.get("parameter name 2");

Depending on your exception handling strategy, you might want to throw an exception instead of returning null in the get method.


Wednesday May 27, 2009

Fabian on Twitter

I am giving this newfangled thing called Twitter a try. I like it so far. (As a side effect, Adobe Air now sneaked onto my system through TweetDeck.) If you are interested in my struggles with tools and code you can follow me at:

Talks about Metro at JavaOne 2009

We are having quite a couple of talks this year at JavaOne and CommunityOne about Metro. Here is a list sorted by date:

S305138: Metro Web Services, NetBeans® IDE, GlassFish® Application Server, and OpenSSO in Action with Amazon WS, Azure, and Office Monday, June 01, 1:40 PM - 2:30 PM
BOF-5261: Web Services in Practice Tuesday, June 02, 9:30 PM - 10:20 PM
TS-4617: Using Java® Technology in the Windows Azure Cloud via the Metro Web Services Stack Wednesday, June 03, 11:05 AM - 12:05 PM
TS-4883: Coding REST and SOAP Together Wednesday, June 03, 4:10 PM - 5:10 PM
BOF-5305: Java® API for XML Web Services (JAX-WS) 2.2 Wednesday, June 03, 7:45 PM - 8:35 PM
TS-4402: Metro Web Services Security Usage Scenarios Thursday, June 04, 9:30 AM - 10:30 AM

Tags: Web Services, Project Metro, JAX-WS, JavaOne

Friday Feb 27, 2009

Metro 2.0 on Java SE 6

We have recently had reports in the Metro user forum where people that ran Metro 2.0 with Java SE 6 had trouble using wsimport. They would typically get errors like this:

parsing WSDL...

generating code...

Copying 2 files to
Created dir:
Created dir: /Users/fr159072/tmp/WebApplication8/build/web/META-INF
Copying 1 file to
Copying 3 files to /Users/fr159072/tmp/WebApplication8/build/web
Compiling 6 source files to
cannot find symbol
symbol  : constructor
location: class
cannot find symbol
symbol  : constructor
location: class
        super(wsdlLocation, ECHOSERVICE_QNAME, features);
cannot find symbol
symbol  : constructor
location: class
        super(wsdlLocation, serviceName, features);
3 errors

For a detailed analysis when exactly this is happening, see this Wiki page. The reason for these failures is that Metro 2.0 contains JAX-WS 2.2, which clashes with JAX-WS 2.1 1 that is built into Java SE 6. You will only see these failures if you did not install Metro 2.0 with our installation scripts metro-on-glassfish.xml/metro-on-tomcat.xml. That is the case if you e.g. installed Metro 2.0 for GlassFish V3 via the update center or if you use a version of GlassFish V3 built into NetBeans.

The simplest solution is to download the Metro 2.0 nightly build and run the installation script. The script copies the file webservices-api.jar, which contains the JAX-WS 2.2 API, into <java-home>/lib/endorsed. Alternatively, you can of course manually copy webservices-api.jar into a suitable endorsed directory.

Tags: Web Services, Project Metro, JAX-WS, Java

1Java SE 6 update 3 and older contains JAX-WS 2.0.

Wednesday Jan 14, 2009

Speed up NetBeans projects on Mac OS X

I found a lot of tips how to build your NetBeans projects faster with the help of tmpfs. However tmpfs is not available for Mac OS X as far as I can tell. Fortunately Mac OS X already has a RAM disk built in that is just as good for this purpose. (That is what tmpfs really does, it provides a RAM disk that is mounted like any ordinary filesystem.)

The following is not really specific to NetBeans or NetBeans projects. You can speed up almost any application that relies on many file operations this way. A nice side effect is that not only NetBeans builds but also NetBeans itself works much faster that way, i.e. file scans and other operations in the IDE that used to take a longer time, are almost instantanious after the change.

The easiest way to use the Mac OS RAM disk is through this donationware utility: Espérance DV. If you really like the command line, you can achieve the same with the help of the hdid service that is built into Mac OS.

No matter how you do it, create a RAM disk, copy your project into it and point NetBeans to it. That's it. In my case, for a large project with lots of file operations during the build, unzipping archives, copying around lots of files, etc. my build finished five times faster than before. That's a huge deal when you run these builds all the time.

There are some drawbacks of course. It is a RAM disk after all, i.e. once the power is gone so are your files. That can be fatal when your system suddenly hangs and needs to be powercycled for example. Espérance DV has an option to save your files to a disk image and restore them from there but you need to manually initiate the saving. That is good enough I guess when you regularly reboot your system unless you forget to press the save button. It won't help however when the system freezes. I haven't tried it out but I hope that Time Machine automatically backs up the RAM disk, which would allow you to restore the content again should it be wiped out accidentally.

Tags: , , ,

Friday Nov 07, 2008

OSGIfying Metro for GlassFish V3

Metro has been a part of GlassFish for a long time now and provides the GlassFish web services implementation. That goes of course for the newly released GlassFish V3 Prelude as well. One of the most important points of GlassFish V3 from an implementation point of view is that it is based entirely on OSGI. This means that all modules like Metro that go into GlassFish have to be provided as OSGI bundles. That is why we recently released Metro 1.4, which is also included in GlassFish V3 Prelude. The main feature it provides is that it makes OSGI bundles of Metro 1.4 for GlassFish V3 available. If you want to install the latest version on GlassFish V3, you do not download Metro yourself anymore. Instead use the update center. We are still making Metro available as an ordinary download of course for non-GlassFish V3 installations.

I wanted to talk a little about the technical challenges we had in creating OSGi bundles from Metro. OSGi is very well suited to develop a large modular system like Metro from scratch. It is not quite as easy however to convert a large base of existing code and libraries into an OSGi bundle. Metro consists of app 30 - 40 libraries, many of which are e.g. basic XML libraries that have developed over many years and are used in a huge variety of applications. Many of the libraries are not actually owned by the Metro project but are third party libraries, e.g. Woodstox. In other words, changing code or even starting to use OSGi services internally was not practical.

Ideally, we would have created separate bundles for every technology contained in Metro. Unfortunately, that would have meant lots of work and so we decided to stick with two bundles, one for JAXB and one for the rest of the Metro stack. The reason that we singled out JAXB was its unique approach that allows JAXB 2 to ensure backwards compatibility with JAXB 1.0. JAXB 2 is packaging the JAXB 1.0 classes in its JAR file. It puts these classes into a subdirectory so that an ordinary Java classloader can not find them. JAXB 2 implements its own classloader that will load the JAXB 1.0 classes when someone uses the JAXB 1.0 API. Unfortunately, that approach confused the Bnd tool that we are using to create our OSGi bundles. It created entries for the JAXB 1.0 classes with bogus package names because it interpreted the subdirectory as part of the package name. That would later confuse the OSGi container when loading classes. Since JAXB is supposed to use its own classloader in this case, we did not want these classes to show up in the OSGi manifest at all. We ultimately extracted the JAXB 1.0 classes, running the Bnd tool on the remaining classes and then readding the JAXB 1.0 classes to the OSGi bundle.

What caused most work was that we had such a big amount of libraries with an uncontrollable amount of dependencies. As I explained before, many libraries have developed over many years and are used by large amounts of applications. Additionally, we found that the OSGi classloaders are not able to deal with e.g. loading of property classes unless the packages containing these properties are declared. We would have had to go through thousands of packages and analyze which ones we really needed to expose. Moreover, as soon as a version of a library changes, you have to check again if any change has an impact on your OSGi manifest. We finally concluded that our best option was to export all Metro packages, no matter if they were supposed to be used by other clients or not. That option is certainly not worse than what you have with any Java application where all public classes in the classpath are accessible throughout the entire JVM.

All in all, putting such a large collection of libraries into OSGi bundles is a worthwile exercise because it helps to point out incorrect dependencies. At the same time, you have to realize that it can be a lot of work depending on how far you are prepared to take the conversion.

Tags: , , , , ,

Wednesday Oct 29, 2008

Metro 1.3.1 uploaded to Maven 2 repository

We released Metro 1.3.1 a couple of weeks ago but forgot to upload it to our public Maven repository. I just rectified that. Use as the Maven address. Thanks to Kohsuke for reporting it: Metro 1.3.1 missing in Maven.

Tags: , , ,

Tuesday Oct 07, 2008

Metro installation for Java 6

Recently I changed the Metro installation scripts based on this discussion in the forum. We used to always install webservices-api.jar into the Java 6 runtime endorsed system directory. That was necessary with Java 6 update 3 and earlier Java 6 releases because Java 6 contained the JAX-WS 2.0 API while current releases of Metro ship with JAX-WS 2.1. Since update 4 however JAX-WS 2.1 is part of Java 6 and there is no need to use the endorsed mechanism anymore. So now we are installing webservices-api.jar into the endorsed directory only if the script is run with an older version of Java 6.

Note that Java 5 installations are not an issue here because Java 5 does not include any JAX-WS API. I was considering for a while whether we should install into a system endorsed directory in the first place instead of an application specific endorsed directory. However, some tools and applications are not designed with that in mind and we want to remain backwards compatible.

Tags: , , ,

Friday Sep 19, 2008

Running Findbugs with Ant Tasks for Maven

We have been using Findbugs for quite a while now to help us find and squash bugs before they can do any harm. It is an excellent tool. Findbugs is directly integrated into our Ant build scripts and is run with every build. Findbugs provides an Ant task that makes it easy to integrate into Ant.

For the integration you have to install Findbugs of course or provide the libraries with the rest of the Metro workspace. We did not want to require a manual installation for every developer because that seemed just inconvenient. And we did not want to check the libraries into our workspace because that workspace and the downloadable distributables are already bigger than we would like them to be. Hence we chose an approach that I have not seen documented in its entirety anywhere else.

The solution is primarily provided by the eminently useful Ant Tasks for Maven. They allow you to execute a couple of Maven related tasks from an Ant build script. And one of the useful things you can do with them is download Findbugs from a Maven repository within your Ant build script. Integrating the tasks is straight-forward:

<target name="maven-init">
    <typedef resource="org/apache/maven/artifact/ant/antlib.xml">
            <pathelement location="lib/maven-artifact-ant-2.0.4-dep.jar" />
    <remoteRepository id="maven.repository" url=""/>

The above makes sure Ant knows about the new Maven tasks and declares a repository from which we will be dowloading Findbugs. This target is designed to be reused by other targets, not just the one that is downloading Findbugs. But back to integrating Findbugs into our Ant script. This here does the interesting part of the work:

<target name="findbugs-base" depends="maven-init">
    <dependencies pathId="findbugs.classpath"
        <remoteRepository refid="maven.repository"/>
        <dependency groupId="net.sourceforge.findbugs"
    <typedef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask">
        <classpath refid="findbugs.classpath"/>
    <pathconvert property="findbugs.classpath">
        <path refid="findbugs.classpath"/>

The dependencies task is one of the Maven tasks we integrated in the previous step. It does all the work of downloading a recent version of Findbugs from the Maven repository that we declared earlier. After the download we can go ahead and declare the findbugs Ant task. The dependencies task helped with that by setting the findbugs.classpath path to the classpath of the Findbugs library and all of its dependencies that were just downloaded. Finally, since we have some tasks later that need a property with this path, we convert the path to a property with pathconvert. Now we can go ahead and actually use Findbugs:

<target name="findbugs-html" depends="findbugs-base"
    <findbugs output="html" 
        <class location="${build.classes.dir}"/>
            <path path="${run.classpath}"/>
        <sourcePath path="${src.dir}"/>

The above simply invokes the findbugs task that we had downloaded in the previous step. You can see that we are using the findbugs.classpath property in the classpath attribute. That is why we had to convert the path into a property. According to the Findbugs documentation, the findbugs task requires that you set a home attribute that points to the Findbugs installation directory. In this case however we don't have a Findbugs installation directory. Maven downloaded the libraries in a very different layout to the local disk. Fortunately, we can use that in conjunction with an undocumented feature of the findbugs task. The trick lies in declaring the classpath and pluginlist attributes. classpath simply needs to point to the Findbugs libraries that we downloaded earlier. pluginlist should point to the coreplugin library that comes with Findbugs. You can of course point to additional plugins in that attribute. The coreplugin was downloaded by Maven together with the rest of Findbugs. We can easily guess the location because Maven uses a fixed directory and structure in your home directory where it stores downloaded libraries.

Tags: , ,




« April 2014