Re: [jakartaee-platform-dev] Batch+CDI integration: proposal to continue

["Scott Kurz" <skurz@xxxxxxxxxx>]

Thanks Reza,

Yes we're talking about batchlets, listeners, readers, writers and processors:  the spec-defined artifacts analogous to servlets, etc. in the table at: https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/specification/src/main/asciidoc/platform/ResourcesNamingInjection.adoc#a651  

My experience from Batch 1.0 is that users wanting to inject CDI beans were able to figure out, without too much confusion, that they could add a @Dependent on the batch artifact, or set BDM=all (yes the move from CDI 1.0 to 1.1 BDM may have required some re-learning but for all CDI users not Batch especially).

The argument Romain and I are making is that this is easy enough for new/naive users.   For more advanced users, it is preferable to just defer to CDI rather than inventing (from the batch perspective), or continuing the pattern (from the platform perspective) the behavior for a hybrid, not-quite-CDI injection into a non-bean artifact use case, and define custom "hybrid" rules.

I do see time constraints as an issue and don't want to rush.   However, the proposal now mostly would just standardize what people have been able to do since 2013.  

True, at one point I was arguing the opposite case:  to support CDI injection into a non-bean batch artifact.     I was taking for granted that this was the expected norm that most would agree on when bringing a component spec into the Platform, and integrating with CDI, and a well-known pattern from integrating other specs.

It does seem late to be defining any new behavior, though, but possibly not too late to ratify existing behavior, if we can reach consensus from both the Batch & Platform perspectives.

Appreciate you trying to get more feedback,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

"Reza Rahman" ---11/09/2021 09:59:02 AM---I do hope there are other folks still left that can provide the institutional knowledge. If not, may

From: "Reza Rahman" <reza_rahman@xxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/09/2021 09:59 AM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Batch+CDI integration: proposal to continue NOT injecting CDI beans into non-bean Batch artifacts
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>

---

I do hope there are other folks still left that can provide the institutional knowledge. If not, maybe the answer is to form that institutional knowledge now.

I prefer what I think would be easiest for users, which would be to just support injection by default rather than needing to convert over to CDI beans when needed. That said, I honestly have not seen that need in Bach usage in the wild that much and in general people seem to just make batch artifacts CDI beans anyway. So maybe in this case it’s fine. I may also be missing an understanding of all the cases where injection may be needed. Is it more than just batchlets, listeners, readers, writers and processors? I think it’s fine to expect those will probably be CDI beans, that’s what I have seen most people do anyway.

If part of the issue is time constraints before the next release, is it better to just leave options open until we can get more Batch end user input? It’s surprising so few people have chimed in so far. I’ll try to see if I can change that.

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.

---

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Tuesday, November 9, 2021 9:37 AM
To: jakartaee-platform-dev
Subject: [jakartaee-platform-dev] Batch+CDI integration: proposal to continue NOT injecting CDI beans into non-bean Batch artifacts

Hi,

I wanted to get some Platform-level input for the discussion we're having in Jakarta Batch re: CDI integration

The key question is whether it's OK to continue only doing CDI bean injection into Batch artifacts that are themselves beans (via the CDI-defined standard mechanims:  BDA, etc.) , rather than injecting into any Batch artifact (as the Platform requires for other specs like Servlet, etc.).

An easy starting point to read the argument laid out is the last message:
https://www.eclipse.org/lists/jakartabatch-dev/msg00226.html
plus the two previous embedded in this reply (from me and from Reza), but you maybe don't have to read the whole thread.

So we're proposing formalizing the current behavior (which in EE 7 in Batch 1.0 had been maybe sort of implied but not mandated as Batch was CDI-aware but tried to be DI-neutral for Spring Batch, etc.).

I do think there's a counter-argument that says the way integration is done in the Jakarta platform is to support CDI injection into "special" artifact instances defined by the component specs, as described in this table:
https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/specification/src/main/asciidoc/platform/ResourcesNamingInjection.adoc#a651  
and thus Batch should follow this pattern.

In the thread you'll see more pros and cons (I won't rewrite them here for now).  

But it does seem to me like the Platform should have a common approach or at least some "institutional knowledge" to guide each spec as it integrates with CDI.

Thank you,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev