Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236
I also hate the spring so just focus on Java EE context to be aligned with the best for the future

On Mon, 2 Dec 2019, 17:08 Tibor Digana, <tibordigana@xxxxxxxxxx> wrote:
Spring is not EE. Pls understand it that Spring is your competitor!!!
Don't mind about the Spring and my advice forget Spring and take your own way.
They will try to support EE API in Pivotal but still Spring is not on your side.

On Mon, Dec 2, 2019 at 4:50 PM Werner Keil <werner.keil@xxxxxxx> wrote:
Well maybe because for Batch there just isn't so much demand to add new features or even recreate everything from scratch? ;-)
 
Especially Jakarta Batch was shaped and inspired as much by the "OSS" de facto standard Spring Batch as no other spec I could think of, so it may be there is no need for change or innovation in this area.
Spring Batch https://spring.io/projects/spring-batch is still at version 4.2.0 while most of the other Spring stack are version 5 now, so that shows, in the Spring platform it also is not so important any more.
 
Werner
 
 
Gesendet: Montag, 02. Dezember 2019 um 16:41 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
Hi Werner,
 
I don't know who should be told more in project team and lead.
The frequency of the emails is small in dev mailing list, so I guess everybody can find the spare time to read all emails.
The OSS was created to get critical reactions from the users community. This is wanted and if the Jakarta would not change and listen then this project will die. Therefore it must be their primary wish of the team leads to listen all the emails and I should not be a postman.
 
Cheers
Tibor17
 
On Mon, Dec 2, 2019 at 3:42 PM Werner Keil <werner.keil@xxxxxxx> wrote:
 
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
_______________________________________________
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
_______________________________________________
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

Back to the top