removal of job artifacts

[fcorneli]

This patch makes JobRepository injectable. It also makes removeJob and removeJobInstance to propagate down to the JDBC database.

[jamezp]

I need to look at how the JobRepository is used internally, but my initial thought is I don't like making it a public part of the API. Things like JobRepository.createStepExecution() should not be exposed. In fact we should find a way to make this not public at all.

I do think it's valid to have an API to remove batch jobs. I just think it needs to be a new API.

@chengfang Thoughts?

[chengfang]

@fcorneli many thanks for your thoughts and patches. Yes, we do need some administration mechanisms to delete certain past jobs. We have plan to support them via WildFly CLI or admin console. But as @jamezp mentioned, our current thinking is not to expose JobRepository as a public API, since this type of tasks belong to batch job administration rather than batch application developement.

[fcorneli]

The JobRepository interface is indeed exposing much more than just the job repository artifact remove operations. How about introducing an interface that is limited to these job repository artifact remove operations, which JobRepository simply extends? Regarding the CLI/admin console integration, you need to expose such an interface from within JBeret somehow, no? In my view, job artifact removal is not 100% orthogonal to the batch application itself, i.e., the batch application might be in a much better position to decide which historical job artifacts can be safely removed compared to some devops admin.

[fcorneli]

our current thinking is not to expose JobRepository as a public API, since this type of tasks belong to batch job administration rather than batch application developement

How about the Java SE runtime requirement set by the JSR 352? There you do not have any notion of 'batch job administration', i.e., no application server admin console or such.