14.8. Implementing ActionLifecycle and ActionPipelineProcessor
A single instance of a class implementing either the ActionLifecycle or ActionPipelineProcessor interface is instantiated on a "per-pipeline" basis (in other words, per-action configuration) and must be thread safe. The
initialise and destroy methods can be overridden to allow the action to perform resource management for the lifetime of the pipeline. (For example, caching resources needed in the initialise method, then cleaning them up in the destroy method.)
These actions must define a constructor which takes a single
ConfigTree instance as a parameter, representing the configuration of the specific action within the pipeline.
The pipeline will invoke each method directly provided that the action has implemented the appropriate interface and that the method names are not overridden in the configuration. Any method invocations which are not implemented via the interfaces, or which have been overridden in the action configuration, will be invoked using reflection.
To simplify development there are two abstract base classes provided in the codebase, each implementing the appropriate interface and providing empty stub methods for all but the
process method. These are org.jboss.soa.esb.actions.AbstractActionPipelineProcessor and org.jboss.soa.esb.actions.AbstractActionLifecycle. Use them like this:
public class ActionXXXProcessor extends AbstractActionPipelineProcessor {
public ActionXXXProcessor(final ConfigTree config) {
// extract configuration
}
public void initialise() throws ActionLifecycleException {
// Initialize resources...
}
public Message process(final Message message) throws ActionProcessingException {
// Process messages in a stateless fashion...
}
public void destroy() throws ActionLifecycleException {
// Cleanup resources...
}
}