Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative)

I am looping in Ed and Arjan here. I think they would be the best people still around to best explain the specification, TCK and API work done in JSF to support CDI without needlessly disrupting Spring based deployments. It has allowed Majorra and MyFaces to continue to work with Spring when CDI is not enabled/present. I believe the TCK simply checks if CDI is present and enabled before running a particular set of tests.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On 4/6/2021 8:37 AM, Scott Kurz wrote:

Though I floated the idea of making CDI + Batch integration a hard requirement, that was just one of a few options. The consensus seems to have steered more towards making CDI + Batch integration optional.

Though one could ask: "how is that different from the status quo?", my answer is that we should require specific behavior in the presence of CDI, and validate this in the TCK, whereas today the TCK and spec say nothing at all about this.

I'm hearing from Romain that other specs/TCKs provide for this type of "CDI optional" stance (JSF?) ... but I'm not familiar with the details. We need to formalize this beyond just an informal agreement that you can choose to not run certain tests and describe your impl differently.

If no one here is familiar enough to point to the formal approach used in these other specs I can do some research and get back to us.
---

That all said, Michael, do you see the rough approach of "formally defining the integration of Batch + CDI, where CDI is optionally present" as breaking Spring Batch apps? I would think not so I'd like to learn more about your concern.

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

Inactive hide details for Romain Manni-Bucau ---04/06/2021 01:44:41 AM---Le mar. 6 avr. 2021 à 00:30, Michael Minella <mminellaRomain Manni-Bucau ---04/06/2021 01:44:41 AM---Le mar. 6 avr. 2021 à 00:30, Michael Minella <mminella@xxxxxxxxxx> a écrit : > Do keep in mind that

From: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 04/06/2021 01:44 AM
Subject: [EXTERNAL] Re: [jakartabatch-dev] GitHub milestones for EE 10 , Batch 2.1 (tentative)
Sent by: "jakartabatch-dev" <jakartabatch-dev-bounces@xxxxxxxxxxx>







Le mar. 6 avr. 2021 à 00:30, Michael Minella <mminella@xxxxxxxxxx> a écrit :
    Do keep in mind that the Spec as it currently exists does not have any CDI specific functionality in it. The alignment to CDI may break implementations. For example, I wouldn't expect Spring's DI to work going forward which is obviously breaking for us.

Strictly speaking it is already there since at least batch property injection are cdi oriented so components can be CDI beans by design, so no breaking change to add more about CDI for spring: https://github.com/eclipse-ee4j/batch-api/blob/0019b27531b3b7d640555bbec94ec7cf3285beca/api/src/main/java/jakarta/batch/api/BatchProperty.java#L41.
Once again, Spring JBatch implementation already bypasses CDI support so will not change much.
That said there is no feature Spring will not support almost natively AFAIK, Spring has an event bus too, Spring has scopes too so sounds all good, TCK just needs to ensure both features are abstracted in the test and the vendor must provide the impl to let the TCK be abstract.
It is the way all specs do it and not sure the point to make JBatch different since at the end it does not prevent Spring usage at all - you can take JAXRS as an example, Spring does not respect the CDI part but Spring users are still happy to use it from what I saw.
  

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

Back to the top