| Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236 |
Hi Mark, Hi all,I like to have JSR 352 and 236, that's why my company used it, but in another fashion, I would say, and in more EE Beans Context friendly style which would speedup my s/w development of the projects.Perhaps the dev community should evaluate the classes in javax.enterprise.concurrent, see [1], and differentiate between internal needs (for e.g. Async in JAX-RS and application servers) and the external needs in the users community. Me as a user expected this API in JSR 236 to fulfil my needs in order to schedule Tasks in ManagedScheduledExecutorService instead of doing it in EJB Timer, of course the ThreadPool should understand the CDI context because my comnay is using the CDI.I don't have a problem with pom.xml batch-jobs xml.I have a problem with practical use of the beans introduced in JSR 352 and I have problem with the way how the beans (via proxy) in JSR 236 are used in terms of beans context.I am still pointing to the practicle use. I have discovered several issues with these two specifications.Therefore I am saying that these specs should be reworked to better ones.The Batch API was initially found as needed API for our company but we spent unpleasant time while discovering the issues with Beans Context.The JSR 236 was found as a substitution of EJB Timer but again it had problems with Beans Context, strange Proxying style, strange way to enable transactions, etc.It would be enough to say in the spec that the Managed*ExecutorService should be able to work with CDI beans with Application scope and Request scope and then Jakarta EE can remove ContextService, "executionProperties".Internally, the application server may still have to use the ManagedExecutorService (not appear in JavaDoc) but the enduser may prefer (should be in JavaDoc) another API, something like this:@RequestScopedpublic class ShortLifecycleBean implements Runnable {@Inject EntityManager em;public void run() { ... }}@ResourceManagedScheduler<ShortLifecycleBean> scheduler;// NOTICE: the Runnable is not in the first parameter because the ManagedScheduler will "call us and we will NOT pass our bean to ManagedScheduler" => IoCFuture<?> f = schedule( trigger );Therefore the new interface ManagedScheduler is the manager of the beans again!CheersTibor17On Mon, Dec 2, 2019 at 11:09 PM Werner Keil <werner.keil@xxxxxxx> wrote:_______________________________________________Nobody says it should be completely removed, but similar to e.g. Jakarta Connectors which also target primarily mainframe or large ERP apps like SAP, JBatch may at most remain part of a „Full Profile“ if that will Always be the sum of ALL Specs and no optionality was desired for that profile.
If the likes of SOAP or JAXB are About to be made optional in the near future, I’d say the same should be discussed for Connectors or Batch.
Werner
Sent from Mail for Windows 10
From: reza_rahman
Sent: Monday, December 2, 2019 23:01
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236
There is definitely a space for batch processing in cloud native Java, as mainframe workloads are slowly but surely migrated. It would be good to see JBatch evolve to be ready for that.
Personally I think the current API is a pretty good start. There are certainly many happy Spring Batch users. I don't see why JBatch can't be evolved to achieve the same or better, especially on the cloud. The basic API and concepts are virtually identical.
Reza Rahman
Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
PS: A big +1 on evolving Jakarta Concurrency. There is a lot of promise there for an exciting set of enhancements.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Scott Kurz <skurz@xxxxxxxxxx>
Date: 12/2/19 2:19 PM (GMT-05:00)
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236
I agree that while discussion on what the requirements should be for the platform to support batch (or not) belong on this list, discussions about how to evolve Jakarta Batch would be better moved to the Batch mailing list.
The Jakarta Batch (successor of JSR 352) mailing list address is: jakartabatch-dev@xxxxxxxxxxx and you can subscribe here: https://accounts.eclipse.org/mailing-list/jakartabatch-dev
With EE 8 recently completed and EE 9 focused on package rename, this list has been quiet, but this is a good time to start looking forward at EE 10 and new function.
We've long recognized the opportunity to have a better CDI+Batch integration. As Werner pointed out, the history of reaching a middle ground with SpringBatch took us down a compromise path of omitting this integration from the core spec... though I believe Apache BatchEE and JBeret implemented some level of integration (the details of which I forget though).
But anyway, your ideas on bean integration and cloud enablement sound interesting, so hopefully we can continue the discussion over in the batch list.
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Compute Grid
Development and Level 3 Team Lead
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102544
skurz@xxxxxxxxxx
--------------------------------------------------------Hamed Hatami ---12/02/2019 01:53:27 PM---I also hate the spring so just focus on Java EE context to be aligned with the best for the future
From: Hamed Hatami <hamedhatami2012@xxxxxxxxx>
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 12/02/2019 01:53 PM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
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-236Hi 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_______________________________________________
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
