Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Batch+CDI integration: proposal to continue NOT injecting CDI beans into non-bean Batch artifacts
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
--------------------------------------------------------

Back to the top