WS-Policy and more

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: http://twitter.com/ritzmann.

Posted at 04:06PM May 27, 2009 by Fabian Ritzmann in Sun  |  Comments[1]

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

Posted at 03:51PM May 27, 2009 by Fabian Ritzmann in Sun  | 

Metro 2.0 on Java SE 6

parsing WSDL...

generating code...

wspolicy/provider/wsdl/server/Echo.java
wspolicy/provider/wsdl/server/EchoResponse.java
wspolicy/provider/wsdl/server/EchoService.java
wspolicy/provider/wsdl/server/Echo_Type.java
wspolicy/provider/wsdl/server/ObjectFactory.java
wspolicy/provider/wsdl/server/package-info.java
Copying 2 files to
/Users/fr159072/tmp/WebApplication8/build/web/WEB-INF/wsdl/NewWebServiceFromWSDL
wsimport-service-generate:
Created dir:
/Users/fr159072/tmp/WebApplication8/build/web/WEB-INF/classes
Created dir: /Users/fr159072/tmp/WebApplication8/build/web/META-INF
Copying 1 file to
/Users/fr159072/tmp/WebApplication8/build/web/META-INF
Copying 3 files to /Users/fr159072/tmp/WebApplication8/build/web
library-inclusion-in-archive:
library-inclusion-in-manifest:
wsimport-service-compile:
Compiling 6 source files to
/Users/fr159072/tmp/WebApplication8/build/web/WEB-INF/classes
/Users/fr159072/tmp/WebApplication8/build/generated/wsimport/service/wspolicy/provider/wsdl/server/EchoService.java:47:
cannot find symbol
symbol  : constructor
Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
        super(ECHOSERVICE_WSDL_LOCATION, ECHOSERVICE_QNAME,
features);
/Users/fr159072/tmp/WebApplication8/build/generated/wsimport/service/wspolicy/provider/wsdl/server/EchoService.java:55:
cannot find symbol
symbol  : constructor
Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
        super(wsdlLocation, ECHOSERVICE_QNAME, features);
/Users/fr159072/tmp/WebApplication8/build/generated/wsimport/service/wspolicy/provider/wsdl/server/EchoService.java:63:
cannot find symbol
symbol  : constructor
Service(java.net.URL,javax.xml.namespace.QName,javax.xml.ws.WebServiceFeature[])
location: class javax.xml.ws.Service
        super(wsdlLocation, serviceName, features);
3 errors

Posted at 04:35PM Feb 27, 2009 by Fabian Ritzmann in Sun  | 

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: NetBeans, tmpfs, Mac OS X, RAM disk

Posted at 04:39PM Jan 14, 2009 by Fabian Ritzmann in Sun  |  Comments[1]

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: Web Services, Project Metro, Project Tango, WSIT, GlassFish V3 Prelude, OSGi

Posted at 04:20PM Nov 07, 2008 by Fabian Ritzmann in Sun  |  Comments[2]

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 com.sun.xml.ws:webservices:1.3.1 as the Maven address. Thanks to Kohsuke for reporting it: Metro 1.3.1 missing in Maven.

Tags: Web Services, Project Metro, Project Tango, Maven 2

Posted at 03:14PM Oct 29, 2008 by Fabian Ritzmann in Sun  | 

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: Web Services, Project Metro, Project Tango, Java

Posted at 02:31PM Oct 07, 2008 by Fabian Ritzmann in Sun  | 

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">
        <classpath>
            <pathelement location="lib/maven-artifact-ant-2.0.4-dep.jar" />
        </classpath>
    </typedef>
    <remoteRepository id="maven.repository" url="http://www.ibiblio.org/maven2/"/>
</target>

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"
                  useScope="runtime">
        <remoteRepository refid="maven.repository"/>
        <dependency groupId="net.sourceforge.findbugs"
                    artifactId="findbugs"
                    version="1.3.2"/>
    </dependencies>
    <typedef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask">
        <classpath refid="findbugs.classpath"/>
    </typedef>
    <pathconvert property="findbugs.classpath">
        <path refid="findbugs.classpath"/>
    </pathconvert>
</target>

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" 
              outputFile="${build.dir}/findbugs.html"
              stylesheet="fancy.xsl"
              classpath="${findbugs.classpath}"
              jvmargs="-Xmx256m"
              pluginlist="${user.home}/.m2/repository/net/sourceforge/findbugs/coreplugin/1.3.2/coreplugin-1.3.2.jar"
              excludefilter="findbugs-exclude.xml">
        <class location="${build.classes.dir}"/>
        <auxClasspath>
            <path path="${run.classpath}"/>
        </auxClasspath>
        <sourcePath path="${src.dir}"/>
    </findbugs>
</target>

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: Ant, Findbugs, Maven 2