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
This is all good stuff and good feedback the batch specification should consider. Totally agree it is not the most effective audience here.

I also don't know about the practical need to totally reinvent the batch API. Frankly I don't think the vendors would be too cool with that and it is perhaps overkill. Evolving the specification I think is a smarter way to go but again, the discussion should start with the folks focused on batch, not the folks here.

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.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Werner Keil <werner.keil@xxxxxxx>
Date: 12/3/19 11:08 AM (GMT-05:00)
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236

 
Tibor/all,
 
Can you please keep that stuff and details of Concurrency or JBatch in their dev mailing lists?!!! :-(
 
It's spamming the mailing lists of platform project, Spec Committee or similar if each individual detail of each individual spec is discussed here.
Those of us who need to look up such details will read the archives or subscribe to extra lists, for the others it is just noise and distraction for the Bad of Jakarta EE as a whole, I trust you would not like to put unnecessary roadblocks in the way of it, do you?
 
Cheers,
Werner
 
Gesendet: Dienstag, 03. Dezember 2019 um 15:21 Uhr
Von: "Tibor Digana" <tibordigana@xxxxxxxxxx>
An: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>, "Mark Struberg" <struberg@xxxxxxxx>
Betreff: Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236
fixed typo:
Future<?> f = scheduler.schedule( trigger );
 
On Tue, Dec 3, 2019 at 3:17 PM Tibor Digana <tibordigana@xxxxxxxxxx> wrote:
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:
 
@RequestScoped
public class ShortLifecycleBean implements Runnable {
  @Inject EntityManager em;
 
  public void run() { ... }
}
 
@Resource
ManagedScheduler<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" => IoC
Future<?> f = schedule( trigger );
 
Therefore the new interface ManagedScheduler is the manager of the beans again!
 
 
Cheers
Tibor17
 
On 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
--------------------------------------------------------

Inactive hide details for Hamed Hatami ---12/02/2019 01:53:27 PM---I also hate the spring so just focus on Java EE context to bHamed 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-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_______________________________________________
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