| Re: [jakartabatch-dev] Kick off conversation on next Jakarta Batch release - Jakarta EE 10 ? Batch + CDI integration? |
Thanks all for the quick and interesting replies.
Romain, I'll have to probably spend some time getting a handle on your ideas but will try to take a look. It sounds like your idea might fit more with a new project, e.g. "Jakarta Reactive Batch" than continuing this one, but this ML is a fair place to discuss for now.
>On Mar 23, 2021, at 11:27 AM, Michael Minella <mminella@xxxxxxxxxx>
>wrote:
>
>
> Thanks Scott for kicking this conversation off. As you noted in your
>comment, the decision for not requiring CDI was made at the time due
>to the interest in having Spring Batch implement the JSR without
>rewriting a large portion of Spring Batch. To be clear, I still see
>that this is the right approach. I'm not clear as to how requiring
>CDI at the spec level improves the experience for the user of this
>specification. We allow an implementation to require a specific DI
>implementation and that seems to work fine, giving the end users the
>type of choice, we would expect. I personally, would like to see a
>list of functionality we want to enable via CDI that is not available
>otherwise. Again, what does requiring CDI support do for the end
>user? Keep in mind, the actual configuration of jobs/etc is
>completely independent of the CI infrastructure to the user.
Michael, one case we've gotten feedback on is that it's cumbersome to have only the single user data object to pass via Job/StepContext and users would like to use CDI beans with a selection of existing scopes and new job/step batch scopes.
CDI also would allow sharing data between the app hosting JobOperator client submitting the job and the job's batch artifacts, without having to parameterize via JSL properties (some overlap with the use of job builder APIs for this but some difference).
I don't see how to provide portability here without picking a specific DI implementation, with the scopes, and mechanisms like qualifiers, etc. it provides, and the natural choice for Jakarta Batch is to take advantage of the rest of the Jakarta platform, leading to CDI.
CDI support also opens the door to other ideas such as integrating with CDI events, (not seeing that on the issues list right now, but pretty sure the idea's been raised).
>
>You pose three options. The first one is to require CDI, the second
>(CDI is optional) is really what we currently have (no required
>changes), and the third then introduces this odd situation of
>requiring CDI only in specific situations that really doesn't help
>those who choose not to use CDI in the first place. For me, I only
>see choice one and two as the real options. I don't see any
>implementation that does not use CDI duplicating the effort both
>across their other DI of choice and CDI.
The key difference from the status quo I'm envisioning is to somehow define the Batch integrated CDI behaviors, and write TCK tests that enforce them.
Today each implementation is free to integrate with CDI however it wants. There are maybe some de facto rules or constraints already implied by CDI at the platform level but this is the grey area I'm hoping to pin down and clarify.
E.g. should a CDI `RequestScoped` context be propagated from JobOperator "client" to executing job? Should any of the other scopes? This needs to be clarified to achieve portability within the platform when using CDI.
In my mind all of these three enforce Batch + CDI behavior, and the question would be what, if anything, would be said about impls that didn't support this.
> To be 100% transparent, as
>Spring Batch evaluates the roadmap for Spring Batch 5 (built on top
>of Spring Framework 6, etc), we are actively considering depricating
>our implementation of JSR-352 and removing it in Spring Batch 6. The
>number of users consuming Spring Batch via the spec is too small to
>warrant the ongoing maintenance burden.
Appreciate you being transparent and pointing that out.
> Add to that, we were never
>able to fully validate our implementation due to the transaction
>pieces of the TCK being dependent upon the entire application server
>certification process (unable to run in an SE environment).
This sounds like something that could be addressed along with my other 'batch-tck' idea there. Originally we were constrained by Oracle's construction of the EE TCK (CTS) framework, and we never made our own standalone SE TCK 100% equivalent.
(And, as mentioned, we're in the unhappy state of needing to commit the tests twice now.)
>From: Reza Rahman
>For me, option three is the way to go. It gives CDI users guarantees
>of what to expect in environments where CDI is available whilst not
>impacting non-CDI users and implementations. The CDI related items on
>the current issue list is a good representation of gaps seen in Batch
>when used in Jakarta EE runtimes.
>
>I believe this is the approach used by Faces fairly successfully in
>supporting use in both Jakarta EE and non-Jakarta EE environments.
>
>Reza Rahman
>Jakarta EE Ambassador, Author, Blogger, Speaker
Reza. Option three does seem like one way to compromise.
The thing I dislike about this is if you distill it to the bottom-line takeaway: "if you want Jakarta Batch to be 100% portable across all impls then avoid CDI". This seems to me in some ways exactly contrary to what we should aspire for the Jakarta platform.
Ture, once you achieve a certain level of expertise, you can better understand what would tie you to either Spring, CDI, etc. and judge that against your desire for portability. But I think sometimes people evaluate the implementations against these portability statements early on in the cycle, and the simple "it's all portable" is what a spec should aim for.
I do wonder if another way to compromise, from the perspective of getting CDI to work with Spring, would be to package a CDI impl like Weld right into your app, along with the Spring Batch and other impls. Could this be feasible? I've never tried it or read about it.
If so we could view the unit of portability as the Java classes & XML artifacts defining the job rather than the WAR/EAR package. That seems like it could potentially be useful to me, if the interest is there.
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------