First, I used the basic HTTP test setup. Now however, I needed Jetty to provide a HTTPS connector. For this to work, Jetty – just like any other webserver, such as apache – needs a server certificate and a private key in a keystore. To create the keystore, I simply followed the excellent Jetty SSL guide. Namingly, I did this (using Ubuntu, see the above link for alternatives):

openssl genrsa -des3 -out jetty.key
openssl req -new -x509 -key jetty.key -out jetty.crt
openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
$JAVA_HOME/bin/keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore

Once I had the keystore set up, I placed it in the src/main/resources folder (the root of the classpath, in case you’re not a maven user) and extended the HttpTestServer like so:

import java.net.URL;

import org.junit.Ignore;
import org.mortbay.jetty.Connector;
import org.mortbay.jetty.security.SslSocketConnector;

/**
 * A test server for testing SSL requests.
 *
 * @author Olaf Otto
 */
@Ignore
public class SslTestServer extends HttpTestServer {
	private static final int HTTPS_PORT = 50443;

	public SslTestServer() {
	}

	public SslTestServer(String mockData) {
		super(mockData);
	}

	@Override
	protected void configureServer() {
		super.configureServer();
		Connector secureConnector = createSecureConnector();
		getServer().addConnector(secureConnector);
	}

	private Connector createSecureConnector() {
		SslSocketConnector connector = new SslSocketConnector();
		connector.setPort(HTTPS_PORT);
		URL keystoreUrl = getClass().getClassLoader().getResource("keystore");
		connector.setKeystore(keystoreUrl.getFile());
		connector.setKeyPassword("test");
		return connector;
	}

	public static void main(String[] args) {
		SslTestServer server = new SslTestServer();
		try {
			server.start();
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}
}

(I added the @Ignore annotation as I placed the class in the test sources folder, though it’s not a test…)
You might use it in your JUnit-based test like so:

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

/**
 * @author Olaf Otto
 */
public class MySslTest {
	private SslTestServer _server;

	@Before
	public void startServer() throws Exception {
		_server = new SslTestServer();
		_server.start();
	}

	@After
	public void stopServer() throws Exception {
		_server.stop();
	}

	@Test
	public void mySsltest() {
		_server.setMockResponseData("<xml>My client expects this response</xml>");
		// Perform tests on port 50443...
	}
}

Here is the whole package as a maven 2 project (including the keystore with a self-signed certificate). Download, unzip, and give it a try (mvn test).

As an alternative, one may simply replace the backend with a mock HTTP server that does one thing: deliver the expected webserver response – i.e. XML data – when called by the client. All you need to set this up is a HTTP server and a pre-recorded service response (quite often this comes with WS client specifications). If you don’t have this data, you can record it, for example using a proxy server in between your WS client and a real WS backend, or a tool such as wireshark.

The recorded XML response thus represents your assumptions against which you test the client. This makes your tests fast, lightweight and a lot better to understand.

Here is my Jetty-based test HTTP server:

package de.sysbsb.test;

import static javax.servlet.http.HttpServletResponse.SC_OK;
import static org.apache.commons.io.IOUtils.write;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.commons.io.IOUtils;
import org.junit.Ignore;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.HttpConnection;
import org.mortbay.jetty.Request;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;

/**
 * A server for answering HTTP requests with test response data.
 *
 * @author Olaf Otto
 */
@Ignore
public class HttpTestServer {
	public static final int HTTP_PORT = 50036;

	private Server _server;
	private String _responseBody;
	private String _requestBody;
	private String _mockResponseData;

	public HttpTestServer() {
	}

	public HttpTestServer(String mockData) {
		setMockResponseData(mockData);
	}

	public void start() throws Exception {
		configureServer();
		startServer();
	}

	private void startServer() throws Exception {
		_server.start();
	}

	protected void configureServer() {
		_server = new Server(HTTP_PORT);
		_server.setHandler(getMockHandler());
	}

	/**
	 * Creates an {@link AbstractHandler handler} returning an arbitrary String as a response.
	 *
	 * @return never <code>null</code>.
	 */
	public Handler getMockHandler() {
		Handler handler = new AbstractHandler() {

			public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch) throws IOException, ServletException {
				Request baseRequest = request instanceof Request ? (Request) request : HttpConnection.getCurrentConnection().getRequest();
				setResponseBody(getMockResponseData());
				setRequestBody(IOUtils.toString(baseRequest.getInputStream()));
				response.setStatus(SC_OK);
				response.setContentType("text/xml;charset=utf-8");
				write(getResponseBody(), response.getOutputStream());
				baseRequest.setHandled(true);
			}
		};
		return handler;
	}

	public void stop() throws Exception {
		_server.stop();
	}

	public void setResponseBody(String responseBody) {
		_responseBody = responseBody;
	}

	public String getResponseBody() {
		return _responseBody;
	}

	public void setRequestBody(String requestBody) {
		_requestBody = requestBody;
	}

	public String getRequestBody() {
		return _requestBody;
	}

	public static void main(String[] args) {
		HttpTestServer server = new HttpTestServer();
		try {
			server.start();
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}

	public void setMockResponseData(String mockResponseData) {
		_mockResponseData = mockResponseData;
	}

	public String getMockResponseData() {
		return _mockResponseData;
	}

	protected Server getServer() {
		return _server;
	}
}

You can use it in a JUnit test like so:

package de.sysbsb.test;

import java.io.IOException;
import java.io.InputStream;

import org.apache.commons.io.IOUtils;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;

/**
 * @author Olaf Otto
 */
public class MyClientTest {
	private HttpTestServer _server;

	@Before
	public void startTestServer() throws Exception {
		_server = new HttpTestServer();
		_server.start();
	}

	@After
	public void stopTestServer() throws Exception {
		_server.stop();
	}

	@Test
	public void someClientTest() throws IOException {
		_server.setMockResponseData("<xml><testdata>hello, world</testdata></xml>");
		// or as a much more elegant alternative:
		_server.setMockResponseData(getRecordedResponse("testdata.xml"));
		// run your client tests, using the HttpTestServer.HTTP_PORT
	}

	private String getRecordedResponse(String recordedResponseFile) throws IOException {
		InputStream testDataStream = getClass().getClassLoader().getResourceAsStream(recordedResponseFile);
		return IOUtils.toString(testDataStream);
	}
}

Here are is the HTTP test server and a JUnit test example as a maven 2 project.

java.nio.charset.Charset.defaultCharset()

So please don’t use messy, old workarounds such as this:

byte [] byteArray = {'a'};
InputStream inputStream = new ByteArrayInputStream(byteArray);
InputStreamReader reader = new InputStreamReader(inputStream);
String defaultEncoding = reader.getEncoding();

Which, unfortunately, is one of the first things you stumble upon when searching for this topic.

When working with enterprise integration you will quite often deal with the integration of legacy systems.

I was recently tasked with the integration of webservices and much to my surprise there are huge issues when attempting to integrate old webservices (i.e. pre axis-2 and pre jax-ws webservices).

These webservices use outdated or unsupported methods, such as rpc-style/encoded communication, or even worce, outdated elements in the XML messages, for instance <multiref>’s. Having to integrate such services of course implies that you cannot change anything on the server side, and thus the outdated format must still be consumed by your webservice client.
This however is a huge problem, since the current WS implementations, such as the popular axis2 framework, do simply not support these outdated formats.

What surprised me the most about this is that webservices are designed to make systems independent by defining a common communication and data format, which is the exact opposite of what is going on here – and these formats are not that old, actually, they where pretty common just about 5 years ago.

Developers facing these issues are taking rather desperate measures to work around these problems, such as using on-the-fly XSLT transformation to convert incoming and outgoing WS messages. However, this binds your application even stronger to the outdated format and specific service data.

In my case I wanted to use Spring-remoting. Since the service was RPC-style, I wanted to use the JaxRpcPortProxyFactoryBean to create an on-the-fly proxy implementing the service interface. What I did not want to do is having to write any additional code to consume the service. Furthermore, I wanted the complex objects transferred by the services to be represented by standard JAVA beans, and not be generated using the wsdl2java axis1 tools since they contain a lot of ugly dependencies. Here is how I got this to work.

Using Spring-remoting’s jax-rpc support with axis 1

Required maven dependencies

First, I was willing to make the compromise of having axis1 on my classpath. This might not be the way to go for everyone, unless you are using an OSGI framework, which was not an option in my case. Using jax-rpc with axis1 from spring requires the following dependencies (I am using maven’s dependency management for the sake of simplicity):

<dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>commons-discovery</groupId>
  <artifactId>commons-discovery</artifactId>
  <version>0.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis-jaxrpc</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis-saaj</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>wsdl4j</groupId>
  <artifactId>wsdl4j</artifactId>
  <version>1.6.2</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-aop</artifactId>
  <version>2.5.6</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-web</artifactId>
  <version>2.5.6</version>
</dependency>
<dependency>
  <groupId>cglib</groupId>
  <artifactId>cglib-nodep</artifactId>
  <version>2.2</version>
</dependency>

Note that this setup is for JDK 1.5. JDK 1.6 ships with quite a lot of jax-ws libraries, so you might want to check whether all of these dependencies are still required when using 1.6, but they might.

Configuring the service using the port proxy factory bean

First, I downloaded the WSDL’s from the services and placed them within my src/main/resources folder to use them offline. This is not required, but I do recommend it. The Next step was to set up the factory beans for jax-rpc in order to let Spring generate implementations of my service interfaces:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

  <bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
    <property name="serviceInterface" value="my.package.MYServiceInterface" />
    <property name="wsdlDocumentUrl" value="classpath:path/to/my/wsdl.swdl" />
    <property name="namespaceUri" value="namespace/as/defined/in/wsdl" />
    <property name="serviceName" value="ServiceNameFromWsdl" />
    <property name="portName" value="PortNameFromWsdl" />
    <property name="servicePostProcessors">
      <list>
        <!--
          This is for mapping your POJO's to the complex service objects (if you are using any).
          You can use an arbitrary number of mapping <bean> configurations for every model
          namespace of your WSDL.
        -->
        <bean
          class="org.springframework.remoting.jaxrpc.support.AxisBeanMappingServicePostProcessor">
	  <!-- encoding style as in WSDL, in my case the outdated soap/encoding -->
          <property name="encodingStyleUri" value="http://schemas.xmlsoap.org/soap/encoding/" />
          <property name="typeNamespaceUri" value="namespace/for/models/as/defined/in/wsdl" />
          <property name="beanMappings">
            <props>
              <prop key="my.package.MyPojo">ModelNameInWsdl</prop>
            </props>
          </property>
        </bean>
      </list>
    </property>
  </bean>
</beans>

If the service specifies an operation such as ComplexResponseVO getResults(ComplexRequestVO), you would thus define an interface like so:

public interface MyService {
     MyResponsePojo getResults(MyRequestPojo);
}

And map the MyResponsePojo and MyRequestPojo using the AxisBeanMappingServicePostProcessor in the above spring configuration. Spring will serialize and deserialize the pojos using standard getter and setter methods to obtain the values, thus you do not have to care for serialization or marshalling. In fact, your pojos do not even have to be Serializable.

Once you have this stuff up and running, you can inject the MyService implementation into any other spring bean and use it like any other bean. Spring will convert the usually annoying and unrecoverable RemoteExceptions into unchecked remote exceptions, thus if you want to handle these, catching remote access exceptions is recommended.

Using an interface as the service representation has the additional advantage that it is pretty easy to fake or mock the service for integration testing.

Handling uppercase data type attributes

Legacy services sometimes violate the JAVA standards of good coding and specify uppercase attribute names for their data types. This is like writing

public class MyService {
     private SomeType MyFieldName;
     ...
}

And thus pretty ugly. When using spring’s JaxRpcPortProxyFactoryBean things are getting a lot worce: the BeanDeserializer will look for a getter/setter pair (aka “property”) to set a value obtained from the Webservice. Such a property must, by specification, start with a lowercase letter. However, in case of an uppercase attribute in the webservice, the Beandeserializer will look for an uppercase property – and will never find it. In example you’d have a getter/setter pair getMyfieldName() / setMyFieldName() that translates to the java beans property “myFieldName”, however the deserializer will look for a “MyFieldName” property. This is a known issue in Axis 1.x, and there is no fix released for it (and most likely there will never be one).

I solved the problem by providing a subclass of the org.apache.axis.encoding.ser.BeanDeserializer to the JaxRpcPortProxyFactoryBean using a subclassed AxisBeanMappingServicePostProcessor and a customized BeanDeserializerFactory:

<bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
...
  <property name="servicePostProcessors">
    <list>
      <bean class="my.package.MyServicePostProcessor">
      ....

Here is the sourcecode for this post processor, the deserializer factory and deserializer:

The post processor:

package my.package;

import javax.xml.namespace.QName;
import javax.xml.rpc.encoding.TypeMapping;

import org.apache.axis.encoding.ser.BeanSerializerFactory;
import org.springframework.remoting.jaxrpc.support.AxisBeanMappingServicePostProcessor;

/**
 * This {@link AxisBeanMappingServicePostProcessor} registers a
 * {@link MyBeanDeserializerFactory} during
 * {@link #registerBeanMapping(TypeMapping, Class, QName) mapping registration}.
 *
 * @author Olaf Otto
 */
public class MyServicePostProcessor extends AxisBeanMappingServicePostProcessor {

  /**
   * Registers the {@link MyBeanDeserializer} for the given mapping.
   */
  @Override
  @SuppressWarnings("unchecked")
  protected void registerBeanMapping(TypeMapping mapping, Class javaType, QName wsdlType) {
    mapping.register(javaType, wsdlType, new BeanSerializerFactory(javaType, wsdlType), new MyBeanDeserializerFactory(javaType, wsdlType));
  }
}

The deserializer factory:

package my.package;

import javax.xml.namespace.QName;

import org.apache.axis.encoding.Deserializer;
import org.apache.axis.encoding.ser.BeanDeserializerFactory;
import org.apache.axis.encoding.ser.EnumDeserializer;

/**
 * This {@link BeanDeserializerFactory} provides a {@link #getGeneralPurpose(String) general-purpose}
 * deserializer {@link MyBeanDeserializer capable of handling local names not conforming to the java beans spec}.
 *
 * @author Olaf Otto
 */
public class MyBeanDeserializerFactory extends BeanDeserializerFactory {
  private static final long serialVersionUID = -8880103201020594221L;

  @SuppressWarnings("unchecked")
  public MyBeanDeserializerFactory(Class javaType, QName xmlType) {
    super(javaType, xmlType);
  }

  /**
   * Returns either:
   * <ol>
   *       <li>
   *           The super types general-purpose deserializer if the target type or
   *           the XML type is <code>null</code> or the pre-defined deserializer class
   *           is an {@link EnumDeserializer}
   *      </li>

   *      <li>A {@link MyBeanDeserializer} otherwise (standard case)</li>
   * </ol>
   *
   *  @return never <code>null</code>, rather throws a {@link RuntimeException}.
   */
  @Override
  protected Deserializer getGeneralPurpose(String mechanismType) {
    Deserializer deserializer;
    if (javaType == null || xmlType == null || deserClass == org.apache.axis.encoding.ser.EnumDeserializer.class) {
      deserializer = super.getGeneralPurpose(mechanismType);
    } else {
      deserializer = new MyBeanDeserializer(javaType, xmlType, typeDesc, propertyMap);
    }
    return deserializer;
  }
}

The deserializer:

package my.package;

import static org.springframework.util.Assert.hasText;

import java.util.Map;

import javax.xml.namespace.QName;

import org.apache.axis.description.TypeDesc;
import org.apache.axis.encoding.DeserializationContext;
import org.apache.axis.encoding.ser.BeanDeserializer;
import org.apache.axis.message.SOAPHandler;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;

/**
 * This {@link BeanDeserializer} takes care of non-normal local names,
 * i.e. local names starting with an uppercase character.<br />
 * Such a local name, usually derived from a WSDL description, will
 * lead to a property lookup for a getter/setter pair on the target bean of the deserialization
 * with an uppercase name start. However, all property names start with a lowercase character
 * according to the java beans spec, thus a property with an upper case name start
 * is never found, causing the deserialization to fail.<br />
 *
 * @author Olaf Otto
 */
public class MyBeanDeserializer extends BeanDeserializer {
  private static final long serialVersionUID = 1183255594948119370L;

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType, TypeDesc typeDesc, Map propertyMap) {
    super(javaType, xmlType, typeDesc, propertyMap);
  }

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType, TypeDesc typeDesc) {
    super(javaType, xmlType, typeDesc);
  }

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType) {
    super(javaType, xmlType);
  }

  /**
   * {@link #normalizeLocalName(String) normalizes} the localName and invokes
   * {@link BeanDeserializer#onStartChild(String, String, String, Attributes, DeserializationContext)}.
   */
  @Override
  public SOAPHandler onStartChild(String namespace, String localName, String prefix, Attributes attributes1, DeserializationContext deserializationcontext) throws SAXException {
    String normalizedLocalName = normalizeLocalName(localName);
    return super.onStartChild(namespace, normalizedLocalName, prefix, attributes1, deserializationcontext);
  }

  /**
   * Converts the first character of the local name to
   * {@link Character#toLowerCase(char) lower case}, if it is
   * {@link Character#isUpperCase(char) upper case}.
   *
   * @param localName must not be <code>null</code> and not empty.
   * @return The normalized local name, never <code>null</code>.
   */
  public String normalizeLocalName(String localName) {
    hasText(localName, "The local name must not be null or empty.");
    char localNameStart  = localName.charAt(0);
    String normalizedLocalName = localName;
    if (Character.isUpperCase(localNameStart)) {
      StringBuilder builder = new StringBuilder(32)
                    .append(Character.toLowerCase(localNameStart))
                    .append(localName.substring(1));
      normalizedLocalName = builder.toString();
    }
    return normalizedLocalName;
  }
}

You might also write you own Serializer if you have the problem “in the opposite direction” which, luckily, I didn’t.

Let’s hope the current WS standards are not deprecated this fast…

The best way of doing this avoiding endless recursion is to use apaches RedirectMatch rule, like this:


RedirectMatch ^/$ http://targethost/mywebapp


Easy, agreed. But i’ve seen (and done it wrong my self) quite often…

There was a hardware crash at the hosting center that has caused a complete exchange and re-installation of this server.
I’ve got older backups running now, recent posts are not up yet but will be within the next week.
Posts may still look crappy and outtakes may occur, but for now, a least the older stuff is back online…

Greetings
Olaf


[INFO] Executing: svn --non-interactive copy --file /tmp/...commit . https://subversion..../tags/...
[INFO] Working directory: ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '...' already exists


If you do, you are using subversion 1.5.x which no longer supports tagging from a local working copy, thus causing the unfortunately very misleading error message.

This is a known issue of the subversion sourcecode management (SCM) and there is a simple workaround:

Use the latest 2.x snapshot version of the maven release plugin and configure it to use remote tagging (on the subversion server) rather than tagging from your local copy.

You can do so by

1.) Adding the apache snapshots repository to your plugin repositories list

    <pluginRepositories>
        <pluginRepository>
            <id>apache-snapshots</id>
            <name>Apache Snapshot Repository</name>
            <url>http://repository.apache.org/snapshots/</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </pluginRepository>
        ...
    </pluginRepositories>

2.) Configuring the release plugin’s version and tagging

        ...
        <build>
        ...
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-release-plugin</artifactId>
                    <version>2.0-beta-9-SNAPSHOT</version>
                    <configuration>
                        <tagBase>full url to the tags directory on the svn server</tagBase>
                        <!-- See http://jira.codehaus.org/browse/SCM-406 -->
                        <remoteTagging>true</remoteTagging>
                        <!-- Further non-mandatory but useful settings... -->
                        <preparationGoals>clean install</preparationGoals>
                        <autoVersionSubmodules>true</autoVersionSubmodules>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
        ...
        </build>
        ...

This fixed it for me.

Note: i had problems getting this to function with the scp:// protocol (provider) for my distribution repository. It seems logic, tough, that the choosen provider must support remote tagging, thus i choose the scpexe:// protocol (using a local scp executable) instead, that worked:

...
<distributionManagement>
<repository>
  <id>myReo</id>
  <name>myreo</name>
  <url>scpexe://...</url>
 </repository>
...
</distributionManagement>
...

Apparently, the upcoming 2.0 release of the maven-release-plugin will have remote tagging as default, so if you read this and the 2.0 version has been released, simply using it should do the job.

I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the real world of things – our reality – using an abstract world of things, while preserving most of the properties and relationships we observe in reality.

Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.

Modules larger than classes with OSGI

Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are larger than classes, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: OSGI. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.

Impact of OSGI on the development process

Let me stress out here how important it is to be able to develop, manage and deploy such modules. The larger your system, the more developers your project involves, the longer you maintain it – you will always face the same problem: Developers concurrently working with party of the system that are directly or transitively connected will run into conflicts. You will have different parts of your system requiring different versions of the same library on the same class path. Changing one part of the system will always affect other parts of the system, most of the times in an unplanned fashion.

Test driven developments helps a lot along the way, but you still have a responsibility problem if there’s one team changing something and this causes a problem in a different part of the system, and dependency issues can be a real mess.

This is where OSGI can play out it’s strengths. Not only does it offer you complete, classloader-based module isolation. I believe the greatest benefit lies in the development process: Concurrent development is a lot easier with OSGI bundles than with a huge pile of tightly interconnected classes. You can have a lot of changes in the bundle, while exposing a relatively stable interface through which other components access your bundle’s services. Separation into OSGI bundles can bring the power of the SOA-Idea into “stand-alone” applications, without the massive overhead of connecting systems or components through, for example web services.

Of course, this concept has quite an impact on your way of thinking, since you will start to add a new level of decomposition: Which classes form tightly coupled components that could be isolated from other components and used as a service through a well-defined, slim and easy-to-use interface?

OSGI about to “break through”

Now, why am i so convinced that OSGI is about to finally become as common as using AOP or dependency injection? Because all the popular technologies are just about to embrace OSGI:

• Craig walls (Spring framework) has just finished his book an modular JAVA with the spring framework, featuring OSGI and Spring, a very powerful combination.
• Doug Clarke and Shaun Smith will hold a presentation on persistence and OSGI with eclipselink (the reference implementation of the JAVA persistence API (JPA)), thus suitable persistence mechanisms for this level of modularization are likely to be close at hand.

And if you look at the schedule for the JAX, Europe’s most important software & development conference, there have never been more OSGI topics featured – at least I would doubt that.

In other words: OSGI will soon be so smoothly integrated with you favorite frameworks, IDE’s and API’s that using it will be a breeze – and a must, if you want to take the quality of your development process and software to the next level.

This is, however, a misunderstanding. mvnDebug is there to enable debugging of the maven process and not of the surefire execution – and disabling forking may have various side effects. One of those is the use of Java agents. When using agents, e.g. for loadtime-weaving in the Spring Framework, one often specifies a -javaagent: as a JVM argument for surefire:

<!-- See http://maven.apache.org/plugins/maven-surefire-plugin/ -->
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<!--
			The following must be within one line of code, line breaks will
			cause surefire execution to fail.
		-->
		<argLine>-javaagent:/path/to/myagent.jar</argLine>
	</configuration>

Java agents however must be provided as an argument to the JVM when it starts – which is exactly what happens when surefire “forks”.
Thus: No forking, no agents, since the tests will be executed in the current jvm used to execute maven itself – and that one was not started with a -javaagent argument. In order to execute surefire tests and use agents, the forkMode must at least be “once” (-DforkMode=once).

Thus, leave the forking as it is, and enable remote debugging as described in the surefire plug-in documentation, i.e. without using mvnDebug:


mvn test -Dmaven.surefire.debug


Which will open a remote debugging port at localhost:5005 for the test execution – and use the agents.