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

[Reza Rahman <reza_rahman@xxxxxxxxx>]

I don’t want to belabor this too much, but I am suggesting enabling injection into “plain beans” only when CDI is activated (which makes it unlikely it co-exists with the likes of Spring). If CDI isn’t enabled in the application, just leave things alone so that the likes of Spring can process injection references however it likes.

Is there a probability existing code would break? Sure, but it’s a low probability.

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 Ondro Mihályi <ondrej.mihalyi@xxxxxxxxx>
Sent: Thursday, November 18, 2021 6:03 PM
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Batch+CDI integration: proposal to continue NOT injecting CDI beans into non-bean Batch artifacts

 

Hi,

This is probably a tad premature but one way to reduce breaking backwards compatibility risks is saying @Inject in non-CDI beans will only work if CDI is enabled. It’s unlikely folks use more than one full scale DI framework at the same time (I have never seen a single case in 15+ years).

I'm afraid that the Batch spec now explicitly allows using any DI engine to instantiate Batch artifacts and inject other beans beyond those required by the spec. So if we say that @Inject only works with CDI it would already be a breaking change anyway, even though people rarely use Batch with another DI framework. So I would rather postpone this decision and introduce the braking change when we decide to support option 1.

Ondro