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

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Tibor,
It looks like
others have responded about the issues and where they should be created.
 But, I'll answer your questions about the mailing lists...

Each Specification
Project has their own mailing list.  You should (will?) get more directed
responses from those mailing lists on your suggestions.  If you only
hear crickets after posting to these, then come back to either the Platform
or the PMC and voice your concerns. But, let's start with the respective
components.

Batch:  https://accounts.eclipse.org/mailing-list/jakartabatch-dev
Concurrency:  https://accounts.eclipse.org/mailing-list/cu-dev

You have already
found the Platform mailing list. Here's the PMC mailing list:  https://accounts.eclipse.org/mailing-list/ee4j-pmc

Hope this helps.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:
       Tibor
Digana <tibordigana@xxxxxxxxxx>
To:
       jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
       12/04/2019
01:17
Subject:
       [EXTERNAL]
Re: [jakartaee-platform-dev] Deprecate JSR-352 and rework JSR-236
Sent
by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

---

I think everybody is listening developer
discussion and moving emails is bureaucracy. ok what is "their"
email i should sent this?
I hope it would not end up witht the
words that we are OSS but we basically do not want to change the old specs
but we want to have Native Cloud however we do not know what it is. I wrote
3 ideas for the native cloud and the result is that these is no real list
of ideas for Jakarta EE where we users can actively add more.

On Tue, Dec 3, 2019 at 6:44 PM Guillermo
González de Agüero <z06.guillermo@xxxxxxxxx>
wrote:
Agree with moving to specific lists,
but I also think this was the correct place to *initiate* the discussion
and get some early feedback (which has already happened).

On Tue, Dec 3, 2019 at 5:08 PM Werner
Keil <werner.keil@xxxxxxx>
wrote:
 
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.
 
[1]: https://javaee.github.io/javaee-spec/javadocs/javax/enterprise/concurrent/package-summary.html
 
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 Mailfor 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@xxxxxxxxxxxand 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-batchis 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@xxxxxxxxxxxTo 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@xxxxxxxxxxxTo 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@xxxxxxxxxxxTo 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@xxxxxxxxxxxTo 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