JBeret does have a concept of Java based job construction using builders. While I can go on about that particular API, it does the job.
That said, the specification does not have any documented affordances for Java based job specification. Everything needs to be done through the JSL.
Wildfly provides its own implementation/wrapper for the parts where application code needs to submit jobs, but as the spec doesn't have a way to start a Java based job, I can't use that.
For example, we use CDI quite extensively, and wiring things together using CDI and annotations is quite natural for our Java developers.
As code speaks more than a 1000 words: here's some example code I'd like to be able to write for batch jobs:
@ApplicationScoped
public class ExampleJob
{
@Produces
@Named("exampleJob")
public Job createExampleJob()
{
return new JobBuilder("exampleJob").step(new StepBuilder("exampleStep")
.batchlet(ExampleStep.class.getName())
.build()).build();
}
@Inject
private JobOperator operator;
@Inject
@Named("exampleJob")
private Job exampleJob;
public void startExampleJob() {
Properties pars = new Properties();
pars.addProperty("par1", "foo");
operator.start(exampleJob, pars);
}
}
The properties necessary for providing parameters to a job is also something I'd like to be able to fix.
The wildfly joboperator assumes all configuration is done through the JSL, even though their JavaDoc states that the job definition needs to be available at deployment time. My example does seem to satisfy that requirement, but it doesn't work, as wildfly doesn't register the job because it doesn't exist in XML.
Martijn Dashorst
