Define custom CDI scopes for batch (@StepScoped, @JobScoped), possibly @ChunkScoped along with initialized/destroyed events

[follis]

Originally opened as bug 7288 by rmannibucau

--------------Original Comment History----------------------------
Comment from = rmannibucau on 2015-09-05 09:20:51 +0000

https://java.net/bugzilla/show_bug.cgi?id=5075 exists but doesnt go very far.

Here what a full CDI integration can look like IMO:

• Each "granularity" - job/step/chunk at least - can have its own scope: @JobScoped, @StepScoped, @ChunkScoped. This would include associated listener in the scope to let them share some bean instances
• JBatch events could be associated with synchronous - cause of the previous point - CDI events to let them be observed in a CDI fashion - @observes.

---

Comment from = ScottKurz on 2015-09-11 15:44:06 +0000

First, to recap, at the moment Sec. 11.1 says there is basically one artifact instance per step (or per partition), except for job listeners where there's one per job.

So one view is to say that @JobScoped, @StepScoped, @ChunkScoped scopes would apply to other beans, but not the batch artifacts themselves.

A different interpretation of your idea would have these new proposed scopes apply the batch artifacts themselves.

I can certainly see some use cases where it would be nice to define scopes like these. However, there are more interactions to think through completely from the spec perspective.

Also adding CDI scopes to the artifacts themselves raises the question of how is this supposed to work in the non-CDI case? Are we going to say that a batch container must honor the semantics from a purely batch perspective even if CDI is absent?

Maybe just for simplicity I'm leaning towards the scopes applying to only the other beans.

Will have to coordinate at some point with both the CDI 2.0 and EE 8 specs I'd think.

---

Comment from = ScottKurz on 2015-09-11 15:47:52 +0000

So the observer idea sounds like you're proposing we define some standard batch Event(s) (e.g JobCompletedEvent, JobFailedEvent) that someone could observe.

Do you know if there's any precedent for another EE technology defining standard Event(s)? Not too familiar with the subject.

---

Comment from = rmannibucau on 2015-09-11 16:20:51 +0000

Scopes are not intended to be used by jbatch components but by beans injected in jbatch components - directly or indirectly ie it can be nested as well. Agree the spec is pretty clear @dependent should be used for jbatch components themself, maybe it could be reinforced. The nice thing is once you can inject MyInjection with a scope "job" you can have a striongly typed state of the batch during the runtime and event potentially serialize it in the job persistent state if needed. It is better than JobContext which is not typed and more common in term of API IMHO.

About events: CDI itself does it (when a scope is initialized/destroyed), other spec doesn't yet but I think it is because integration is still a "small glue" but it is often compensated but external projects. Needed code is very small and gain in term of API is quite important so I don't see why we couldn't get it in the spec. Side notes about that: CDI 1.2 has already CDI.current() which would make the integration smooth without the need of any new CDI API.

---

Comment from = ScottKurz on 2016-03-24 16:17:38 +0000

"CDI integration" is going to be a big topic. I think although the various CDI-related pieces will intersect we need to break it apart more.

Let's use this just for the scopes, building on the work in JBeret and BatchEE hopefully.

Some other quick thoughts:

• I'd assume we start by continuing the pattern we established with JobContext/StepContext of having the "thread local"-like behavior, which forces you to code in a distributed partition-ready way. I realize JBeret has a different take on this.

• Do we need our own @ChunkScoped when we already have @TransactionScoped?

• Will we be able to easily specify the order of the chunk scoped initialized/ destroyed event compared with the ChunkListener beforeChunk()/afterChunk()?

[scottkurz]

Perhaps we should include a boolean annotation attribute to specify whether we keep the thread-local behavior of Job/StepContext or not for this scope.

Note that the standard @ApplicationScoped is defined without thread-local behavior.

E.g. we could imagine

@StepScoped(threadLocal=true) // one instance, per-step, per-thread
@StepScoped // one instance, per-step (dflt to 'false')

Or 'threadAffinity'.. or possibly default the other way

[rmannibucau]

@scottkurz cdi 2 got an api to handle threadlocal (request scoped actually) but the issue is it does not have any context propagation and generally speaking, thread local should stay internals so I would recommend to define the scope as exposing related data, if not thread safe the sub component must synchronize it. If thread local is needed, user can always rely on a request scope now.

[scottkurz]

I was really thinking of the @StepScoped(threadLocal=true) case as a way of expressing "partition scoped", which would be another name for it, maybe... although the nice thing about my name is it seems to map better to the top-level step which itself is not a partition thread.

I don't think that's as useful as the StepScoped scope spanning all threads for a given step. Maybe it's not needed in fact. But I didn't think RequestScoped would be meaningful for a batch execution thread. I thought you had to have a web container thread for that (unless or until jakartaee/cdi#474 is developed).

[rmannibucau]

@scottkurz request = thread for cDI (never said it was a good naming :D) but in jbatch it is useful to share a state across threads for the same step and this one is hard to do for end users compared to others

[scottkurz]

Seems we're not going to get to this in 2.1.