JSR 352 How to store an object (java.lang.Object) as a job property?

Question

In JSR352 1.0 Final §9.3 Batch Properties, the batch properties is defined to be type java.lang.String:

Batch applications need a way to receive parameters when a job is initiated for execution. Properties can be defined by batch programming model artifacts, then have values passed to them when a job is initiated. Batch properties are string values.

And here's an example:

Properties jobProps = new Properties();
jobProps.setProperty("props1", "value1");
jobProps.setProperty("props2", "value2");

// start
jobOperator.start("myjob", jobProps);

However, I need to use other objects for the job. This general "property" could be any object type, so java.lang.Object. So I'm looking for a work-around solution which meets the below requirements:

• The property stored should be immutable, which means that once passed to the batch runtime, it won't be changed again.
• The property should be persisted when job stopped and can be reused when the job restarted. (Serializable?)
• The work-around solution should not depend on any implementation, e.g. JBeret from JBoss. Because I'm developing a framework, which let the user to choose their own JSR 352 implementation.

Can anybody help?

Answer 1

Here's the idea I had in mind for your use case (even if it does look like a workaround).

You can populate a persistent object for the life of the job instance (i.e. across restarts) by injecting one or more job parameters as batch properties of an initial step, and then using that initial step's persistent user data with the step configured with allow-start-if-complete="true" to ensure the step always runs.

---

In detail:

The JobOperator interface only lets you pass job parameters to the batch application in the form of a single java.util.Properties object.

So yes, if working around this limitation by using some application or other context (like CDI would provide) isn't a good option, then you'd have to do something like serialize a Serializable (or marshal a JAXB object) and set it as a job parameter.

So taking for granted that you're going to serialize a property named serializedObj, would what the job look like in order to define a job-level object that's persistent and immutable?

Start with a "setup" step like this:

<step id="setup" next="step1" allow-start-if-complete="true">
    <batchlet ref="SetupBatchlet">
        <properties>
            <property name="serializedObj" value="#{jobParameters['serializedObj']}" />
        </properties>  

with an implementation of:

public class SetupBatchlet implements Batchlet, BonusPayoutConstants {

    @Inject
    @BatchProperty(name = "serializedObj")
    private String serializedObjStr;

    @Inject
    private JobContext jobCtx;

    @Inject
    private StepContext stepCtx;

    @Override
    public String process() throws Exception {

        // 1. See if step persistent user data already exists
        MyObject myObj = (MyObject) stepCtx.getPersistentUserData();

        // 2. If not, deserialize
        if (myObj == null) {
            myObj = ...  // deserialize "serializedObjStr"
            // 2a. Persist user data
            stepCtx.setPersistentUserData(myObj);
        }

        // 3. set for use by later steps
        jobCtx.setTransientUserData(myObj);

and now step1 and later steps can do:

MyObject myObj = (MyObject) jobCtx.getTransientUserData();

So this MyObject instance is persistent and immutable. The allow-start-if-complete="true" configuration ensures that the "setup" step always runs, and the JobContext is always populated.

This can scale if you need to aggregate multiple objects though it can get ugly at a certain point; still the same idea can still apply.