Getting Hitched to Oddjob

• Introduction
• The Interfaces
• Extension Points
• The Responsibilities of Being a Parent

Introduction

So far all interaction to Oddjob has been quite casual. All the jobs you've written could be moved to Spring or Expresso, and with a small amount of configuration changes - everything would work.

However if you do decide to settle down with Oddjob - you do get a little bit more.

The Interfaces

Oddjob queries and manipulates it's component through five main interfaces.

• Stateful

  If you want to change how your jobs sate is controlled implement this interface.

• Resetable

  If you want to have your own functionality for the hard/soft reset actions then implment this interace.

• Structural

  If you want to have child components that are visable to others, in Oddjob Explorer, for instance - then implement this interface.

• Stoppable

  Implementing this interface allows a custom stop method.

• Iconic

  Implementing this interface allows a job to provide it's own changeable icon.

Stateful is the interface that Oddjob checks before it attempts to wrap your Runnable job or service. If your component is Runnable or has the service method signature then you must implement Stateful to get custom control over your component.

If your component isn't Runnable or has the service method signature then you can pretty much pick and choose which interfaces to implement.

A FolderJob (which is badly named because it's not Runnable ) just implements Structural, Stoppable and Iconic.

Extension Points

There are a few extension points to provide some help with implementing all those interfaces.

SimpleJob for simple things, and StructuralJob which helps with children.

In both you only need to implement an execute() method. Here's a quick example:

package org.oddjob.devguide;

import org.oddjob.framework.SimpleJob;

public class ExtendedJob extends SimpleJob {

	protected int execute() {
		System.out.println("Hello World!");
		return 0;
	}
}

The Responsibilities of Being a Parent

If your job provides a addComponent() or an addComponentXXX() then a child or children may have been created and will have been handed over for your sole care. As such:

• So if your job is stopped you it should stop it's children.
• If your job is reset, it will probably want to reset it's children.
• If you job is destroy, it absolutely must destroy it's children.

As an aside this responsibility issue is why there is no support for an inline attrribute child. This would be a child which is set using a setXXX method but declared inline in the XML. The set method has no idea where the job came from and so your job can take no responsibility for it and so the job wouldn't get stopped or destroyed and so it's not allowed.