Package org.jesterj.ingest.processors

Class SplitFieldProcessor

java.lang.Object

org.jesterj.ingest.processors.SplitFieldProcessor

All Implemented Interfaces:

Configurable, DocumentProcessor

public class SplitFieldProcessor
extends java.lang.Object
implements DocumentProcessor

Nested Class Summary

Nested Classes

Modifier and Type	Class	Description
static class	SplitFieldProcessor.Builder

Field Summary

Fields inherited from interface org.jesterj.ingest.model.Configurable

VALID_NAME

Constructor Summary

Constructors

Constructor	Description
SplitFieldProcessor()

Method Summary

Modifier and Type	Method	Description
java.lang.String	getName()	A name for this object to distinguish it from other objects.
Document[]	processDocument(Document document)	Mutate, validate or transmit a document.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Methods inherited from interface org.jesterj.ingest.model.Configurable

isValidName

Methods inherited from interface org.jesterj.ingest.model.DocumentProcessor

isIdempotent, isPotent, isSafe

Constructor Detail

SplitFieldProcessor

public SplitFieldProcessor()

Method Detail

getName

public java.lang.String getName()

Description copied from interface: Configurable

A name for this object to distinguish it from other objects. This value is generally supplied by the plan author. Every object in a plan must have a unique name, begin with a letter and only contain letters, digits, underscores and periods.

Specified by:

getName in interface Configurable

Returns:

The user supplied name for this step

processDocument

public Document[] processDocument(Document document)

Description copied from interface: DocumentProcessor

Mutate, validate or transmit a document. Implementations must not throw any * Throwable that is not a JVM Error and should be written expecting the possibility that the code might be interrupted at any point. Practically this means Document processors should perform no more than one persistent or externally visible actions and that action should be transactional. Large complex processors that write to disk, DB, or elsewhere multiple times run the risk of partial completion. Similarly, since JesterJ is a long-running system it will often cease operation due to unexpected outages (power cord, etc.), so it is not a good idea to hold resources that require an explicit release or "return". "Check then write" is of course a performance anti-pattern with respect to external networked or disk resources since network and disk io are typically slow to access. Processors should feel free to set the status of a document and add a status message via Document.setStatus(Status, String, java.io.Serializable...) however the easiest way to communicate a failure (for which all further processing is in error) is to simply throw a runtime exception. The document processor has no need to add the document to the next step in the plan as this will be handled by the infrastructure in StepImpl based on the status of the document so long as the document is emitted via the return value of this method. If the document enters via the parameters and is not emitted for any reason the processor MUST set an appropriate status before the end of this method, though it is preferable to just set the status and emit it.

Specified by:

processDocument in interface DocumentProcessor

Parameters:

document - the item to process

Returns:

The documents that result from the processing in this step. Documents with status of Status.PROCESSING will be processed by subsequent steps, and documents with any other status will have their status recorded and will not be processed by subsequent steps.