Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236

["Werner Keil" <werner.keil@xxxxxxx>]

 

Tibor,

 

Especially the design issues you believe to see in Jakarta Batch in its current form, please share that with the actual project team and lead.

It is one thing to make the platform slimmer and more compact by declaring lesser used specs optional, but completely abandoning an existing spec that has been with the Java EE platform since Java EE 7.

It has not changed since then, ther is no "Batch 2.0", the changes in 1.0.2 were marely cosmetic or updating the namespace to "jakarta", and the "Beans" design you disregard was of course shaped primarily by Spring Batch, which in my impression is the most popular implementation of the Batch standard, so simply throwing that away because you believe there is a better approach may not be so feasible, but making it optional would certainly relieve many vendors from supporting it if they and their customers do not have a strong need.

 

Werner

 

Gesendet: Montag, 02. Dezember 2019 um 15:24 Uhr
Von: "Tibor Digana" <tibordigana@xxxxxxxxxx>
An: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Betreff: Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236

My company found Batch API (JSR 352) useful but the design with Beans in JSR 352 is horrible.

Therefore I am proposing to deprecate it and to create a new one.

There might be voices, as mine, saying that the Steps of the Batch should be Cloud capable and the Steps should be able to fork their execution in Docker via Cloud orchestrator.

Anyway this should be reworked and get the attraction in the future.

So altogether two approaches may exist 1. Steps in one JVM and 2. Steps distributed over multiple JVMs.

 

Regarding the JSR 236 is very important but here is fundamental problem of the designers because they made the Beans a non-beans so that they are totally cutt off the EE context. Therefore I found this API nice but incomplete as it is a good theoretical API with no practicle application in EE Beans managed world.

Anyway the managed threal pool is important from the configuration perspective and therefore manageable. But we require more than this and so the Thread should fully understand the EE context.

 

On Mon, Dec 2, 2019 at 2:28 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Steve,

 

I guess the remarks on JSR-236 should best be raised with the particular spec, but for Batch it is more a question for the platform or Spec Committee etc. to discuss how useful and badly needed some of the specs are compared to others, and in my experience Batch is very little used compared to others like Servlet, REST or CDI.

 

Werner

 

 

Gesendet: Montag, 02. Dezember 2019 um 14:23 Uhr
Von: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
An: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Betreff: Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236

Hi Tibor

 

I would suggest you raise these issues on Jakarta Batch and Jakarta Concurrency so that they can be worked on for Jakarta EE 10.

 

Steve

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Tibor Digana
Sent: 02 December 2019 12:37
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236

 

Hi all,

 

Pls deprecate JSR-352.

 

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 and it does not look like.

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.

 

 

 

Pls rework JSR-236.

 

It is a new problematic API.

I reported issues against the Wildfly due to this API is not practicle in commercial EE world.

You do not have real beans in the executed Task in the ThreadPool.

If you have a producer of EntityManager, these Task bean won't see it!

You won't be able to use the scopes because again as in the previous JSR they do not have the end and therefore the JDBC connection is permanently open.

Pls support using CDI beans in the concurrent Task beans without any additional need to construct them via Proxy.

 

 

Cheers

Tibor17

 

 

 

_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev