| Re: [jakartabatch-dev] Overview of Jakarta Batch 2.1 + CDI integration details |
Since Batch + CDI integration overlaps a bunch of issues in our 2.1 milestone: https://github.com/eclipse-ee4j/batch-api/milestone/1 ) let me level set with a thread here.
My take is that we specify a set of details like this:
1 Batch implementation required to perform CDI injection into batch artifacts (https://githubcom/eclipse-ee4j/batch-api/issues/46)
The Batch implementation MUST be able to load batch artifacts and inject CDI-managed beans (i.e. have the CDI engine inject them, however we'd state it), with or without the presence of BDA on the batch artifacts (i.e. without the batch artifacts needing to be themselves loaded as CDI managed beans), unless CDI is disabled altogether, (e.g. bean discovery mode = none),
This loading with CDI bean injection MUST occur for any of the spec-mentioned artifact loading techniques (i.e. mapping from JSL @ref values): a) CDI bean name(*) b) batch.xml entry c) FQCN (*) - IIRC, we would need to spec the bean name syntax
By default, with BDA=annotated, batch artifacts will not be managed as CDI beans
This will be backed by a statement in the platform spec too (https://github.com/eclipse-ee4j/jakartaee-platform/issues/420),
2. Instance scope for batch artifacts - CDI bean / non-bean
When a batch artifact is loaded but NOT as a CDI-managed bean, the batch implementation MUST ensure artifact instances are scoped to a single JSL reference. This means, for one, that different methods within a given listener will use the same instance for a given step (e.g. StepListener beforeStep/afterStep).
When a batch artifact is loaded as a CDI-managed bean there should be one instance request (TBD: figure out the correct wording) to the BeanManager for each JSL reference. (This ensures again that using a bean with @Dependent-scoped, the default, doesn't result in different instances across e.g. beforeStep/afterStep). However, since the BeanManager is control of instance scope it may not be one instance per JSL reference; e.g. using @ApplicationScoped for a batch artifact could result in one instance per application.
3. Inject JobOperator - (straightforward: https://github.com/eclipse-ee4j/batch-api/issues/17)
4 The Batch implementation MAY provide custom, proprietary techniques for disabling CDI
Strictly speaking there's probably no need to explicitly state this but it does provide continuity speaking to our legacy of trying to define a generic, non/pre-CDI specified behavior.
5. (A miscellaneous consequence worth mentioning) - Don't rely on field initializers https://github.com/eclipse-ee4j/batch-api/issues/73
Since the CDI engine may be in control of @BatchProperty injection, field initializers can not be relied upon to provide a default value in the absence of a corresponding JSL property, and so should be considered a non-best practice (since CDI is a better practice).
I think these artifacts already exist so it's too late to try to ban them. But we should say something in the spec, since the question has come up. Perhaps an implementation would want to issue a warning.
6. Batch defined custom scope
Still on the table: Job/Step-scoped ((https://github.com/eclipse-ee4j/batch-api/issues/79) One issue to clarify is whether we should offer both the "thread local" behavior of JobContext/StepContext and non-thread-affinity scope variants, and what exactly to name them, etc.
(Not sure if we need to specify when standard CDI scope lifecycle event callbacks are made relative to parts of the batch lifecycle or not)
7. Injection of one Batch artifact into another https://github.com/eclipse-ee4j/batch-api/issues/171
I think we've effectivley covered this now. Item 2., above describes instance creation from the batch container artifact loading, and so at this point we can just say "normal CDI rules apply". And of course item 6. elaborates on those rules
---
I think that's it. Did I miss anything? Appreciate your comments/feedback.
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------