Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] Wish: Java based job configuration

I'm curious how JBeret injects @BatchProperty values in the Java-based case.

It's easy for me to map (in my head) from the way artifacts (listeners, readers/writers etc.) are composed into steps/jobs using XML to the way they are composed with these builder APIs.

The XML also introduces this very particular job property subsitution behavior with the scopes, defaults, and use of job parameters.

Does JBeret have another set of Producer(s) built in to supply batch property values ? Or do you write your own?

---

Romain, don't mean to ignore your ideas, just way over my head without seeing a lot more code :)

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Inactive hide details for Romain Manni-Bucau ---02/05/2020 01:13:56 PM---Hi Martijn, Idea is interesting and I would even say: Romain Manni-Bucau ---02/05/2020 01:13:56 PM---Hi Martijn, Idea is interesting and I would even say: why a materialized job? :)

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 02/05/2020 01:13 PM
Subject: [EXTERNAL] Re: [jakartabatch-dev] Wish: Java based job configuration
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx




Hi Martijn,

Idea is interesting and I would even say: why a materialized job? :)

Assume JobOperator underlying registry does not find the xml job, then there are multiple options:


1. It matches a named bean which is a jbatch component, just run it (awesome for batchlets)
2. If 1 fails, fire a StartingJob event enabling to trigger a component, then each stage of a batch can have an event and this way we can chain the batch with observers and instead of prebuilding the job, just need a component executor (likely in the context of the event fired). This makes legacy all the decision chains of the xml and interpolation since it can become actual code: the job is literally dynamic.

What i like with that option is it is CDI native and can be reactive (CDI async events) keeping jbatch instrumentation and reporting whereas other alternatives stays quite aligned on the xml in terms of features IMHO.

Hope it makes sense.

Le mer. 5 févr. 2020 à 18:39, Martijn Dashorst <martijn.dashorst@xxxxxxxxx> a écrit :
    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.

    Documentation for jberet's builders: https://jberet.gitbooks.io/jberet-user-guide/content/programmatic_job_definition_with_java/

    Martijn Dashorst

    _______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartabatch-dev_______________________________________________
    jakartabatch-dev mailing list
    jakartabatch-dev@xxxxxxxxxxx
    To change your delivery options, retrieve your password, or unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartabatch-dev



Back to the top