| Re: [jakartabatch-dev] Kick off conversation on next Jakarta Batch release - Jakarta EE 10 ? Batch + CDI integration? |
"jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx> wrote on 03/24/2021 10:28:17 AM:
> >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. 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.
Despite this concern, I agree with Reza option three gives us a good enough working understanding to move forwards. We could have a set of tests which do something like: "no-op if a call to CDI.current() fails". (Though we still should run this by the overall platform ML).
I don't view this as a final decision. For one, as Michael mentioned, Spring Batch is still considering its stance on Jakarta Batch support.
But having gotten the issue out in the open upfront, I also don't want to hold up any further discussion.
As spec contributor I'm happy to take on the burden of managing our somewhat complicated, nuanced stance on optional DI etc. knowing that it brings Michael and the Spring Batch team into the discussion and access to all their contributions and insight.
The thing I struggle with though is the developer that says: "how do I stick to the spec to write a 100% portable batch job?". If we say "don't use any Spring, don't use any CDI"... well, that's not really setting them up for success.
> From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
> Side note: request scoped issue is not really an issue since request
> scoped is bound to a thread (even in servlet spec it does not follow
> async context lifecycle) and job operator changes of thread by spec
> so it can't be propagated but this is one of the scope we could
> introduce (@ExtendedJobScoped). For other *built-in* scopes it is
> kind of the same (session is bound to the session so decoralated
> from the job lifecycle, applicationscoped is global so shared
> etc...). This is fully due to CDI an should be inherited in JBatch
> otherwise it will conflict with other specs usable with JBatch
> (starting from transaction one which has a transaction scoped which
> is close to request scoped in terms of spec but aligned on the tx -
> so thread as of today - and not inheritable).
Agree, there are already some precedents that constrain how batch would integrate CDI but think we need to spell it all out explicitly.
> +1, bval and cdi already have TCK groups (you can be bean validation
> "se" compliant but not EE or EE (= SE + others) compliant) just by
> configuring the test suite and showing publicly you pass the related
> group of tests.
> AFAIK it is just a matter of expliciting it - as "textually", ie
> defining that com/ibm/jbatch/tck/tests/jslxml defines SE TCK
> and com/ibm/jbatch/tck/tests/jslxml + com/ibm/jbatch/tck/tests/ee
> the full TCK suite (EE).
>
> My 2cts there would be that spring can pass the EE tck since it is
> only about JTA which is well supported by spring so - as of today -
> it is just a matter of doing the *standalone* configuration of the
> tck launcher (it is done AFAIK - no need to run cts setup with EJB
> to pass these tests) and if you target full EE compatibility you run
> it in a EE container - like wildfly/tomee - and disable their jbatch
> impl to run yours instead.
> Not sure any jakarta spec an do better than that: enable standalone
> compat and proove EE integration, sounds like the minimum delivery, no?
While it's possible to "wrap" batch-tck to run in EE in any number of ways, (and in the past year we talked about some ideas, Arquillian - which didn't seem to appeal to many, your JUnit 5 extension idea), we've left this as an exercise to the user.
I don't think it's acceptable to stop here. Consider someone wanting to certify a product like Open Liberty against an entire platform. They can't be expected to hack together a wrapper around batch-tck, and that's why we've continued to contribute (a duplicate) to the overall platform TCK https://github.com/eclipse-ee4j/jakartaee-tck.
I'd like batch-tck to be evolved to a standalone TCK that can be run in SE or EE via a simpler configuration so that we don't have to contribute to the platform TCK any more.
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------