Re: [jakartabatch-dev] Kick off conversation on next Jakarta Batch relea

[Romain Manni-Bucau <rmannibucau@xxxxxxxxx>]

Le jeu. 25 mars 2021 à 14:17, Scott Kurz <skurz@xxxxxxxxxx> a écrit :

"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).

Side note: CDI.current() is not really portable due to weld impl but grouping tests by package/groups/category or anything enabling surefire to run them or not is what all TCK do and I think it is sufficient. The runner is responsible for its test suite anyway at the end.

 

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.    

"don't use spring" is already built-in for any jakarta spec if the app targets to be portable (and it is fine since it is not the goal of jakarta nor spring to make them portable).

Just to illustrate it, their jsr330 (just @inject) impl is different already so you can't target portability between these two worlds, this is why defining CDI portability is the only concern jakarta can target for now and it is fine and does not prevent spring to define the IoC integration as desired for their ecosystem (a bit like jaxrs defines SE/Servlet/EE environments jbatch would define SE/CDI envs).

 

> 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.

On a personal note I don't put it as a high priority task since current TCK runs well in SE and with surefire (batchee does it) but +1 if there is enough resource. 

------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev