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.
It would break all JBatch only cases - without any IoC nor EE container.
It is a very common practise to have CronJob (or plain old crontab ;)) batches in standalone mode with @Inject support as mentionned before - batch property + jobcontext+stepcontext - and an EE instance serving the JobOperator read-only data for admin/monitoring.
So ignoring Spring and Guice is likely ok since Guice never got embraced by users AFAIK and spring abandonned JBatch but standalone AND CDI cases are likely the only ones we must ensure any compatibility, the hybrid case never pops up so we can ignore it in the spec and let it be vendor dependent for now if we can about users and breaking changes.
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
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
