| If you look at the JBeret implementation, that looks about right to me. In general, job configuration would be rather static except for the parameters perhaps. I would expect to define it in a factory or CDI producer and reference it later, ideally in a type safe way or by name in the least. There is a case for dynamically building jobs, but it is fairly rare.
Hopefully the JBeret and Spring Batch folks can chime in? Both should have some implementation experience on this already? Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. On Apr 1, 2021, at 8:49 AM, Scott Kurz <skurz@xxxxxxxxxx> wrote:
I wanted to call out a point on the ML here, on the Java-defined job: https://github.com/eclipse-ee4j/batch-api/issues/109
Are we just looking to provide an API to dynamically construct a job and then go and immediately execute it?
I'm sure that'd be useful. I mean to say, are we ALSO looking to provide an API to "register" the job by name so that it could be easily invoked later, by name and job params, for example?
Using the existing interface for starting an XML-defined job:
start(String jobXMLName, Properties jobParameters)
it's certainly easy to expose that remotely.
I haven't looked at the existing implementations and their approaches yet.
But wondering what people were thinking this would look like?
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev
|
