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

["Scott Kurz" <skurz@xxxxxxxxxx>]

As I'd started to summarize it seemed like I was biasing the vote in favor of my opinions...  but I do see Romain's point and we need to consider that as in relying on the results.    

If I had to summarize positive (+) and negative (-) aspects maybe I'd summarize:

Option 1:
 + Allows new, naive users to avoid getting tripped up over needing to add a BDA, understanding what the right scope is in order to do injection  
 -  More advanced CDI users need to understand the exact boundary of what is and isn't possible in this limited CDI hybrid mode, and the related rules, rather than leveraging their existing understanding of CDI.  

Option 2:
 + New users have a not-too-difficult learning curve in selecting and supplying a BDA to do CDI injection
 + Builds on existing CDI implementation so no new behaviors to learn and no new performance hit to possibly consider (e.g. because of new scanning)
 + Essentially the legacy, and the implementers haven't heard many complaints about the need to add BDA to do CDI injection
 -  Small learning curve for new users but a bit more than Option 1 for very simple use cases
 -  Breaks from precedent of pre-CDI specs within the platforms where "special" artifacts can receive CDI injections

Option 3:
 + Like Option 1, new, naive users find injection just works out of the box
 + Once the batch container registers batch artifacts as beans under a specified scope, the remaining behaviors will be completely described by existing CDI.
 - There will be use cases that will be hard to completely specify.  The fact that job XML discovery isn't fully specified plus the way in which artifacts are loaded at execution time will make discovery of batch artifacts on startup difficult.

I'm not sure that's all that more consumable or likely to be read and digested ... but.... if someone does consult the thread they would now see this.

And you all can reply with your thoughts on that if you want.. I'm sure we'd each say it a bit differently.

But thanks Reza, for starting to publicize the vote.. we have 18 so far it looks like.

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

"Romain Manni-Bucau" ---11/19/2021 03:37:02 AM---Le ven. 19 nov. 2021 à 02:06, Reza Rahman <reza_rahman@xxxxxxxxx> a écrit : > I don’t want to belabo

From: "Romain Manni-Bucau" <rmannibucau@xxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 11/19/2021 03:37 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>

---

Le ven. 19 nov. 2021 à 02:06, Reza Rahman <reza_rahman@xxxxxxxxx> a écrit : 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 


Le ven. 19 nov. 2021 à 02:06, Reza Rahman <reza_rahman@xxxxxxxxx> a écrit :

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_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev