JBERET-483 Implementation and tests for TaskSubmissionListener proposal

[Zerrossetto]

Hi,
this pull request is related to the issue JBERET-483, for a listener around job task submissions in the SE implementation of JBeret.

[chengfang]

what parameters do these 2 methods need? In your application and use case, which info are needed that should be passed in as parameters? org.jberet.spi.JobTask seems a good one, and I think implementers will need to know what JobTask it is in order to determine the appropriate action.

javax.batch.runtime.context.JobContext may be another one, to provide more details about the current job execution.

Also note that jberet JobExecutor is used for not only job execution, but also Split/Flow/Partition executions. If we attach such a listener this way, it will be called upon submission of a job, a flow, split and step partition. Is this what you intend it to be?

[Zerrossetto]

I tried to write an answer to your points multiple times, but more I think of it more I think I underestimated the addition of this feature to the library.

Now, below my original answer.

You definitely have a point with your questions, i was eager to submit the proposal that I ended missing the goal I posed to myself for the submission itself.

What I meant was described in the issue JBERET-483: I wanted for the jberet-se module a clean way to introspect the task submissions (and only the tasks) and, in my specific case, propagate data that is generated during the costruction of the job instance and the job execution to child threads via the TheadFactory object.

Also, by reading your last intervention

If we attach such a listener this way, it will be called upon submission of a job, a flow, split and step partition.

By looking the the references in the code now I get what you meant, I don't wish to have a listener for those objects too, and I don't think having it would be useful. One easy way would be to test the type of task submitted, but I don't really like it.

Another I can think of would probably be to split the generation of the jobtask and the submission, leaving the invoker class the task of rollback the transaction if needed, but this impacts more the current mechanics of the AbstractJobOperator class, (that is jberet-core, so behavior of the EE component is impacted.

On the other hand, it's probably needed to create a new interface on the line of JobTaskInformation, that lets the implementing class expose a minimal amount of information without letting the caller edit the JobContext data.

I would really like to think more about this part and come back with a better pull request. For the moment I think I'll close this one.