The Batch (JSR-352) is problematic in practice. Pls rework the API and fully support CDI

[Tibor17]

I have practical experiences with JSR-352.
It is very problematic API.
The @Transactional, scopes and qualifier do not work in there.
You would not be able to inject the EntityManager produced by CDI producer.
If you inject it via @PersistenceContext, the connection would not be closed because here is no scope of batch in terms of Java EE.
Basically there are outstanding EE beans in this API and therefore it works as another Java SE API.
Additionally, nowadays such jobs are useless without injecting Cloud orchestrator, e.g. Consul, because there you would observe URL pointing to the service executing the Batch Step. Forking such Step would be essential as a new option in a new API.

You have EntityManager CDI producer, and you cannot inject it in the Batch beans of Reader/Processor/Writer. The JBoss still considers these beans as EJB.
You cannot use transactions of CDI in the listeners because there is no Context available and you need to have it because you want to update the state in the state machine.
You want to inject CDI beans but @Inject is not allowed. We do not want to use EJB.
You want to use scoped beans but this API does not know what scope means.
So the workaround is to inject EJB beans and make Async calls in order to use the transactions in the leaf.
Even if you try to use @Transactional in the Processor bean, the JBoss will crash because Arjuna is using it together with the Request scope but this cope is unknown in Batch.

This is really SE style of design and the beans are limited only to the annotations from the API. If I am user of EE I would expect a cooperation between the APIs within the container. I have another view than the API designer. I am the user and I want all APIs to be interconnected without any blocker in the container but this is not hapenning in reality.

[keilw]

@Tibor17 Same here, please recreate in https://github.com/eclipse-ee4j/batch-api/issues, there seems to be no way to transfer it to another organization even for those with admin privileges.
Note, #115 is a perfectly legitimate issue for here because it asks about the inter-dependencies betwen e.g. EJB and other specs or APIs, while your ticket is a detailed change or improvement request for a particular spec, even with the focus on just ONE implementation only, it may not even apply to the API but that's for them to decide.

[johnhogan]

Hello Tibor. Do you have a reproducer project demonstrating the issue?