We decided to move the SVN repository of our project “pulse – the web application framework” from dev.java.net to Sourceforge. However dev.java.net does not provide shell access to the SVN host, so a simple svnadmin --dump / svnadmin --load move was not possible. However, we wanted to keep the complete SVN history, so we started looking for a tool.

rsvndump to the rescue.

Thankfully, Jonas Gehring (saubue) has developed the great rsvndump which saved us a lot of worries. It was painlessly installed on a clean Debian Lenny and off we go:

rsvndump -u username -p secret https://pulse.dev.java.net/svn/pulse | gzip > svndump.gz

The above command line creates the SVN dump from the remote server and compresses it.

Adding the dump to the Sourceforge SVN.

Actually adding the dump to Sourceforge’s SVN is very simple.
First, you have to connect to Sourceforge’s Interactive Shell Service. I used PuTTY to connect to the service which is clearly documented.
Second, upload the dump file to your personal home directory on the Sourceforge server via SFTP:

• Host name: shell.sourceforge.net
• User / Password: your user name and password from Sourceforge

Usually your SFTP client should start directly in your home directory. So just upload the dump.

Once the upload has completed go back to the shell service make sure you are in your home directory by typing “pwd” and unzip the dump with gunzip.

Then the actual import starts in five easy steps:

1. adminrepo --checkout svn will copy your repository to /svnroot/UNIX-NAME so you can work with it from there.
2. Then remove your clone copy of your current repo with rm -rf /svnroot/UNIX-NAME/*
3. Create a new repo with svnadmin create /svnroot/UNIX-NAME/
4. Import the dump with svnadmin load /svnroot/UNIX-NAME < svndump
5. Save your changes using adminrepo --save

And that’s it! :)

Yesterday, I had a very strange issue with a web application of ours. I tried to run it with the current JDK 6 Update 18 on both Tomcat 6 and Jetty 6. The app started fine and after the second click in the browser the JVM started to pump up its heap while putting full load on one CPU core.
At first I thought a recent update in the webapp might have introduced a nice memory leak, but strange enough the very same web application ran fine on Linux (Debian Lenny) using OpenJDK 6.
Next thing I tried, was to downgrade to the previous release of JDK 6 (Update 17): et voilà, the app was behaving as usual. Even after hours of running and using it, the heap was keeping its bounds.
Tests with JDK 5 also showed that the web application seems to be okay.

I tried to nail down the issue using Eclipse’s TPTP and profiled the application, but the JVM was crashing too fast to get any useful results…

Further testing

After futher test today, I realised that the click in the browser was actually the third request to the webapp. A Flash movie on the first page was doing the second, asking for an XML configuration. That made me think – what’s different between the two requests?
Well actually the main difference was the method of output: one request delivered HTML and the other plain XML.

Beware of old versions

The HTML output was generated with an XSLT processor bundled with the webapp – and that version was already two years old. Usually, I would say that should make it safe to use, but in my case it was the problem. After upgrading to the latest version and adapting a view XSL tweaks no longer available in the current version, the app was running fine again.

My, my – that’s one of those days…

Already featured in the previous parts

In the first part we have created the @Injected annotation, an Interface for our units of work (IUnitOfWork) and skeletons for the Injector and the Executor. The second part was all about gathering the Java reflections basics to process the annotated classes. Finally a basic introduction to JAXB has been featured in the third part. Today we will put it all together.

A base directory for all configurations

You already know how to create configuration instance from XML via JAXB and how to find annotated fields. Next we will define a mechanism to resolve the XML files and inject the instance into the annotated field. For our little example, we define that all configurations will be place in one directory “conf” on the root level of out project. The naming convention for the configuration XML files is canonical name of the field declaration + .xml. This allows an easy resolving of the configurations.
Let’s improve our Injector to use the “conf” director and to inject the unmarshaled instances

package dukeslittleb.tutorials.ioc;

import java.io.File;
import java.lang.reflect.Field;

import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;

public class Injector {

	private static final File CONFIG_DIRECTORY;

	private static final JAXBContext JAXB_CONTEXT;

	static {
		// get the configuration directory
		File f = new File("conf");
		if (!f.exists()) {
			throw new RuntimeException(f.getAbsolutePath() + " does not exist");
		} else if (!f.isDirectory()) {
			throw new RuntimeException(f.getAbsolutePath()
					+ " is not a directory");
		} else if (!f.canRead()) {
			throw new RuntimeException(f.getAbsolutePath() + " is not readable");
		}
		CONFIG_DIRECTORY = f;
		try {
			// set up th JAXB context
			JAXB_CONTEXT = JAXBContext
					.newInstance("dukeslittleb.tutorials.ioc");
		} catch (JAXBException e) {
			throw new RuntimeException(e);
		}
	}

	public static final IUnitOfWork setUp(final IUnitOfWork unit) {

		System.out.println("Injector: setting up "
				+ unit.getClass().getCanonicalName());
		for (Field field : unit.getClass().getDeclaredFields()) {
			// check if field is annotated
			if (field.isAnnotationPresent(Injected.class)) {
				System.out
						.println("  Trying to inject into " + field.getName());
				field.setAccessible(true);
				try {
					// inject into field
					field.set(unit, JAXB_CONTEXT.createUnmarshaller()
							.unmarshal(
									new File(CONFIG_DIRECTORY, field.getType()
											.getCanonicalName()
											+ ".xml")));
				} catch (Exception e) {
					throw new RuntimeException(e);
				}
				field.setAccessible(false);
			}
		}
		return unit;
	}
}

Adding some live to the Executor

Now let’s get back to the Executor from part 1 and apply a few changes:

package dukeslittleb.tutorials.ioc;

public class Executor implements IUnitOfWork {

	@Injected
	private IConfiguration conf;

	public void run() {
		System.out.println("running " + this + " with a configuration of type "
				+ conf.getClass().getCanonicalName());
	}
}

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<complex-executor-config>
	<sub-tasks>
		<class>dukeslittleb.tutorials.ioc. HelloWorldUnit</class>
		<class>dukeslittleb.tutorials.ioc. HelloConfigurationUnit</class>
	</sub-tasks>
</complex-executor-config>

Injector: setting up dukeslittleb.tutorials.ioc.Executor
  Trying to inject into conf
running dukeslittleb.tutorials.ioc.Executor@1ad77a7 with a
configuration of type
dukeslittleb.tutorials.ioc.ComplexExecutorConfig

So far, so good.

Spice it up!

Until now the Excutor behaves a bit static. What we want is some more injections. To get that we will first create another interface which extends IConfiguration: IHasSubTasks (the name says it all).

package dukeslittleb.tutorials.ioc;

import java.util.Collection;

public interface IHasSubTasks extends IConfiguration {

	Collection<IUnitOfWork> getSubTasks();
		
}

public void run() {
	System.out.println("running " + this + " with a configuration of type "
			+ conf.getClass().getCanonicalName());
	
	
	if (this.conf instanceof IHasSubTasks) {
		for (IUnitOfWork unit : ((IHasSubTasks) this.conf).getSubTasks()) {
			unit.run();
		}
	}
}

package dukeslittleb.tutorials.ioc;

...

public class ComplexExecutorConfig implements IHasSubTasks {

   ...

   	public List<IUnitOfWork> getSubTasks() {
		List<IUnitOfWork> sTasks = new ArrayList<IUnitOfWork>();
		for (String cn : this.tasks) {
			sTasks.add(Injector.setUp(cn));
		}
		return sTasks;
	}

}

	public static IUnitOfWork setUp(final String cn) {
		try {
			return setUp((IUnitOfWork) Class.forName(cn).newInstance());
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}

Two units of work for demonstration purposes

Finally, we create two additional IUnitOfWork implementations to make use of our new toys. Both implementations are simple and straight-forward.

package dukeslittleb.tutorials.ioc;

public class HelloWorldUnit implements IUnitOfWork {

	@Override
	public void run() {
		System.out.println("Hello World!");
	}

}

package dukeslittleb.tutorials.ioc;

public class HelloConfigurationUnit implements IUnitOfWork {

	@Injected
	private SimpleExecutorConfig conf;
	
	@Override
	public void run() {
		System.out.println(this.conf.getMessage());
		
	}

}

Injector: setting up dukeslittleb.tutorials.ioc.Executor
  Trying to inject into conf
running dukeslittleb.tutorials.ioc.Executor@1ad77a7 with a
configuration of type
dukeslittleb.tutorials.ioc.ComplexExecutorConfig
Injector: setting up dukeslittleb.tutorials.ioc.HelloWorldUnit
Injector: setting up dukeslittleb.tutorials.ioc.HelloConfigurationUnit
  Trying to inject into conf
Exception in thread "main" java.lang.RuntimeException:
java.lang.RuntimeException: javax.xml.bind.UnmarshalException
 - with linked exception:
[java.io.FileNotFoundException: ...

Boom - just as expected. As you can see the Injector is looking for the configuration file "dukeslittleb.tutorials.ioc.SimpleExecutorConfig.xml" to inject conf in dukeslittleb.tutorials.ioc.ComplexExecutorConfig, so let's add it:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<simple-executor-config>
	<message>Hello from XML</message>
</simple-executor-config>

Happy Ending

Now let's do the final run of IOCSample App:

Injector: setting up dukeslittleb.tutorials.ioc.Executor
  Trying to inject into conf
running dukeslittleb.tutorials.ioc.Executor@b8f82d with a
configuration of type
dukeslittleb.tutorials.ioc.ComplexExecutorConfig
Injector: setting up dukeslittleb.tutorials.ioc.HelloWorldUnit
Injector: setting up dukeslittleb.tutorials.ioc.HelloConfigurationUnit
  Trying to inject into conf
Hello World!
Hello from XML

That's it! Now you know how to implement your own custom runtime annotations in Java, how to access fields reflectively (as a matter-of-fact methods work just the same) and how to use JAXB for your Java XML bindings.

What has happened so far?

In the first part we have created the @Injected annotation, an Interface for our units of work (IUnitOfWork) and skeletons for the Injector and the Executor. The second part was all about gathering the Java reflections basics to process the annotated classes.

What’s in it for today?

• A quick introduction to JAXB
• Two simple configurations

JAXB quick start

Okay, we will start with a very simple sample configuration as a POJO (plain old Java object) which we will JAXB-ify directly afterwards.

package dukeslittleb.tutorials.ioc;

public class SimpleExecutorConfig {

	private String message;

	public final String getMessage() {
		return message;
	}

	public final void setMessage(final String m) {
		this.message = m;
	}
	
}

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<simple-executor-config>
	<message>Hello from XML</message>
</simple-executor-config>

...
@XmlRootElement(name = "simple-executor-config")
@XmlAccessorType(XmlAccessType.NONE)
public class SimpleExecutorConfig {

	@XmlElement(name = "message", required = true)
	private String message;
...

package dukeslittleb.tutorials.ioc;

import java.io.StringWriter;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;

public class PrintXMLs {

	public static void main(String[] args) throws JAXBException {
		SimpleExecutorConfig exConf = new SimpleExecutorConfig();
		exConf.setMessage("Hello World");
		print(exConf);
	}

	private static void print(Object obj) throws JAXBException {
		JAXBContext ctx = JAXBContext
			.newInstance("dukeslittleb.tutorials.ioc");
		StringWriter out = new StringWriter();
		ctx.createMarshaller().marshal(obj, out);
		System.out.println(obj.getClass().getCanonicalName());
		System.out.println();
		System.out.println(out.toString());
		System.out.println();
	}
	
}

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><simple-executor-config><message>Hello World</message></simple-executor-config>

Two simple configurations

We have already created the first JAXB-ified configuration which should now look like:

package dukeslittleb.tutorials.ioc;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement(name = "simple-executor-config")
@XmlAccessorType(XmlAccessType.NONE)
public class SimpleExecutorConfig implements IConfiguration {

	@XmlElement(name = "message", required = true)
	private String message;

	public final String getMessage() {
		return message;
	}

	public final void setMessage(final String m) {
		this.message = m;
	}
	
}

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<complex-executor-config>
	<sub-tasks>
<class>dukeslittleb.tutorials.ioc.HelloWorldUnit</class>
<class>dukeslittleb.tutorials.ioc.Hello ConfigurationUnit</class>
	</sub-tasks>
</complex-executor-config>

package dukeslittleb.tutorials.ioc;

import java.util.ArrayList;
import java.util.List;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlElementWrapper;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement(name = "complex-executor-config")
@XmlAccessorType(XmlAccessType.NONE)
public class ComplexExecutorConfig {

	@XmlElementWrapper(name = "sub-tasks")
	@XmlElement(name = "class")
	private List<String> tasks = new ArrayList<String>();
	
	public final void setTasks(List<String> subTasks) {
		this.tasks = subTasks;
	}
	
	public final List<String> getTasks() {
		return this.tasks;
	}

}

On Sunday, the UK newspaper The Independent reported that people who illegally download music from the internet also spend more money on music than anyone else, according to a new study. The survey states that the so-called pirates spent an average of £77 a year on music – £33 more than those who claim that they never download music dishonestly. Disturbing, isn’t it.

Just six days earlier, the New York Times mused about the German government being open for wishes of publishing industry to introduce royalty collection societies to gather and distribute fees for relating to and citing from published articles. Something that would probably make posts like this impossible as well. Great!

The first strike has been traditional publishing industries (music labels and movie houses) to miss the file-sharing trend.

The second strike will probably be software publishers being late on the concept of open source while thumping on software patents.

The third strike – we’ll see, but remember: “three strikes and you’re out”, dear publishing industry…

What has happened so far?

In the first part we have created the @Injected annotation, an Interface for our units of work (IUnitOfWork) and skeletons for the Injector and the Executor.
You can download the complete source as an Eclipse Java project.

What’s next? Using some reflection…

Next we will add a private field to out Executor and introspect it with the Injector’s setUp(IUnitOfWork) method. So let’s add an arbitrary instance variable to the Executor to get a grip on the work done with reflections.

package dukeslittleb.tutorials.ioc;

public class Executor implements IUnitOfWork {

	private Object example;

	public void run() {
		System.out.println("running " + this);
	}
}

package dukeslittleb.tutorials.ioc;

public class Injector {

	public static final IUnitOfWork setUp(final IUnitOfWork unit) {
		System.out.println("Injector: setting up "
				+ unit.getClass().getCanonicalName());
		for (Field field : unit.getClass().getDeclaredFields()) {
			System.out.println("  Field: " + field.getName());
		}
		return unit;
	}
}

Injector: setting up dukeslittleb.tutorials.ioc.Executor
running dukeslittleb.tutorials.ioc.Executor@1d04653
  Field: example

As you can see, retrieving the private fields of a Java class is a piece of cake with reflections using Class.getDeclaredFields(). Also look at Class.getFields() and notice the differences. While the first returns all fields which are declared in the current class regardless of their visibility, the latter returns all public fields of the class’ hierarchy, i.e. of the class, all its superclasses and interfaces.

First fun with our custom annotation

Now let’s add the @Injected annotation to our example field in Executor:

@Injected
private Object example;

package dukeslittleb.tutorials.ioc;

public class Injector {

	public static final IUnitOfWork setUp(final IUnitOfWork unit) {
		System.out.println("Injector: setting up "
				+ unit.getClass().getCanonicalName());
		for (Field field : unit.getClass().getDeclaredFields()) {
			if (field.isAnnotationPresent(Injected.class)) {
				System.out.println("  Field: " + field.getName() + " is of type" + field.getType().getCanonicalName());
			}
		}
		return unit;
	}
}

Injector: setting up dukeslittleb.tutorials.ioc.Executor
running dukeslittleb.tutorials.ioc.Executor@1d04653
  Field: example is of type java.lang.Object

In this tutorial we will be using the canonical name to identify the configuration files required to build injected objects with JAXB. In the next part we will do a little excursus on JAXB and inject our first custom configurations with an extended version of the Injector.

Preface

In this tutorial I will show you how to create a very, very basic dependency injection framework with your own custom annotation. You will need Java 6^TM to do all the examples (you can also use Java 5^TM, but then you will have to download and set up JAXB separately).

Together, we will create a custom annotation to inject our dependency configurations, discover and process the annotation via reflections and add an XML binding for the configurations with JAXB.
I recommend you use an IDE like Eclipse to follow the examples. If you do so, a simple Java project will do the trick.

You can download the complete source as an Eclipse Java project.

Let’s get started – creating the annotation

Since the use of the default package is not a good idea, we will start in a new one for this project, e.g. ‘dukeslittleb.tutorials.ioc’. Now creating an annotation for run-time evaluation (this is what we need) is very easy:

package dukeslittleb.tutorials.ioc;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target(value = { ElementType.FIELD })
public @interface Injected {

}

Preparing the units of work for the injection

Next we will create a very simple interface for the units of work want to tie together with dependency injection.

package dukeslittleb.tutorials.ioc;

public interface IUnitOfWork {

	void run();
	
}

And a simple implementation:

package dukeslittleb.tutorials.ioc;

public class Executor implements IUnitOfWork {

	public void run() {
		System.out.println("running " + this);
	}
}

Okay, let’s start with the injector, which will for now do nothing but print the instances which it gets passed.

package dukeslittleb.tutorials.ioc;

public class Injector {

	public static final IUnitOfWork setUp(final IUnitOfWork unit) {
		System.out.println("Injector: setting up "
				+ unit.getClass().getCanonicalName());	
		return unit;
	}
}

package dukeslittleb.tutorials.ioc;

public class IOCSampleApp {

	public static void main(String[] args) {		
		Injector.setUp(new Executor()).run();
	}

}

Injector: setting up dukeslittleb.tutorials.ioc.Executor
running dukeslittleb.tutorials.ioc.Executor@1d04653

In the next part, we will make a first use of the @Injected annotation and add some life to the injector.