Re: [cu-dev] Concurrency 3.0 pulls ready for review: #43, #103 - and two

["Nathan Rauh" <nathan.rauh@xxxxxxxxxx>]

Reza,

Thanks for your
replies.

I'll add your
vote for @Asynchronous.

Considering some
ideas for simplest solutions, one might be to use Java default methods
to have the interface methods related to serialization be provided but
raise an unsupported error so that only providers that can actually do
serialization would need to implement them.  Although having said
that, I just thought of that it would be possible to have the context provider
SPI start out lacking those methods and then use this same default methods
approach to add them in later, once a third-party provider is identified
which could actually leverage the capability. For now, the CDI spec which
will be the initial user of this (so that third-party implementations of
CDI can plug in to context propagation) has indicated they absolutely do
not want serialization of context.  I didn't find that out until after
I sent my original email, but I probably should have guessed it considering
how most of what would be in a CDI context are not the sort of things to
be persisting across JVMs.  So I'm starting to think that the safest
and simplest thing to do would be to cover only what there is currently
a use case for while ensuring it's extensible enough to adapt to whatever
solution/alternative Java ends up with for serialization if java.io.Serializable
is deprecated and removed.  There will always need to be a tradeoff
regardless between propagating a non-serializable context type like CDI
and being able to persist captured context across JVMs, and the user will
just end up needing to decide which it wants.




From:
       "Reza
Rahman" <reza_rahman@xxxxxxxxx>
To:
       "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:
       10/12/2021
09:38 PM
Subject:
       [EXTERNAL]
Re: [cu-dev] Concurrency 3.0 pulls ready for review: #43, #103 - and two
questions on them
Sent
by:        "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>

---

Hi Nathan,

Firstly thanks for posting this to the
mailing list.

I prefer following EJB naming and call
it @Asynchronous. I think this will serve to make it clear the intent is
to supersede the EJB functionality eventually.

For the Serializable Context issue, I
would favor going with the simplest solution that still allows for providers
to create more robust implementations that cover clustering cases for timers
and batch. I would hate to standardize something that makes that impossible.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger,
Speaker

Please note views expressed here are
my own as an individual community member and do not reflect the views of
my employer.

---

From: cu-dev
<cu-dev-bounces@xxxxxxxxxxx> on behalf of Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: Monday, October 11, 2021 5:46 PM
To: cu developer discussions
Subject: Re: [cu-dev] Concurrency 3.0 pulls ready for review: #43,
#103 - and two questions on them
 
Thanks everyone
who has been reviewing pulls for the Concurrency spec.

The two following pulls could benefit from some additional discussion.

The first of these, for asynchronous methods has thus far received some
good review comments which have all been addressed except for the discussion
on whether to name it @Async or @Asynchronous or @Asynch, which seemed
like a good question to put before the group in case there are any strong
preferences.  Among the reviewers thus far, one had a strong preference
for @Async and others weren't sure or didn't have a strong preference.
Some of the thoughts which have been pointed out thus far:  @Asynchronous
would match the EJB and MP FaultTolerance names, which could be an advantage
or disadvantage.  @Async lines up with the CompletableFuture.*Async
method names.

Issue #43Asynchronous Methods Annotation
pull to review:

https://github.com/eclipse-ee4j/concurrency-api/pull/147

The second of these, for third-party providers of thread context (which
will be useful as a prerequisite to getting CDI context propagation from
a third-party like Weld), is mostly a copy from MicroProfile Context Propagation,
but I want to highlight one aspect that didn't match up because MicroProfile
intentionally excluded a couple of methods to avoid addressing it, which
is the question of whether to allow for Serializable thread context.  The
only place in the specification where this is possible is with the 4 ContextService.createContextualProxy
methods that let you create contextual proxies that can be serialized and
deserialized across JVMs. MicroProfile avoided the problem by excluding
these methods. We could do that, too, by declaring that the combination
of third-party thread context with the createContextualProxy methods is
only valid if the interface types are not serializable. That could simplify
things for providers of third-party context, especially those for which
deserializing context to another JVM makes no sense. But it could also
be limiting in scenarios such as persistent (EJB) timers and potentially
batch that might use the ContextService to store contextual tasks and expect
them to be able to run on another JVM.  What are everyones' thoughts
on this?

Issue #103Third-Party Providers of Thread Context
pull to review:

https://github.com/eclipse-ee4j/concurrency-api/pull/149

From:        Nathan
Rauh/Rochester/IBM
To:        "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:        10/01/2021
03:20 PM
Subject:        Re:
[EXTERNAL] Re: [cu-dev] Concurrency 3.0 pulls ready for review: #43, #35,
#99, jakartaee-schemas #28

---

With  #141for
the resource definition annotations being merged now, I created the corresponding
to update the deployment descriptors with equivalents for the annotations.
This needs a review under the jakartaee-schemas repo, https://github.com/eclipse-ee4j/jakartaee-schemas/pull/29.

Here is the full list of outstanding issues with pulls that still need
a review,

Issue #28Jakarta EE Schema Updates for Resouce Definition Annotations
pull to review:
https://github.com/eclipse-ee4j/jakartaee-schemas/pull/29

Issue #43Asynchronous Methods Annotation
pull to review:

https://github.com/eclipse-ee4j/concurrency-api/pull/147

Issue #35Java SE 8 Date and Time Support
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/143

Issue #99Cron-based Trigger
This builds on the Java SE Date/Time based trigger (#35 above) so it also includes the commit for it.
For only the changes that are unique to this pull, see the following commit:
https://github.com/eclipse-ee4j/concurrency-api/pull/144/commits/8cec1222b66ea6ff68a730d1923fc7355592efe2

From:        Nathan
Rauh/Rochester/IBM
To:        "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:        09/20/2021
04:19 PM
Subject:        Re:
[EXTERNAL] Re: [cu-dev] Concurrency 3.0 pulls ready for review: #38, #46,
#35, #99, #43

---

The pulls for copying from MicroProfile were merged last week.

Next I'll aim to get #140and#141merged, maybe around a week from now.
Let me know if anyone is still in the process of reviewing these.

Also, I've added #147to
the list of pulls open for review,

Issue #38Define Concurrency Resources Portably
This pull is the first step - getting the annotations defined with the most basic attributes.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/141

Issue #46Parallel Stream Support
The most I can see doing for this one is to have ManagedThreadFactory also implement ForkJoinWorkerThreadFactory.  Alternatively, we could do nothing and leave it to the user to implement something similar based on ContextService.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/140

Issue #35Java SE 8 Date and Time Support
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/143

Issue #99Cron-based Trigger
This builds on the Java SE Date/Time based trigger (#35 above) so it also includes the commit for it.
For only the changes that are unique to this pull, see the following commit:
https://github.com/eclipse-ee4j/concurrency-api/pull/144/commits/8cec1222b66ea6ff68a730d1923fc7355592efe2

Issue #43Asynchronous Methods Annotation
pull to review:

https://github.com/eclipse-ee4j/concurrency-api/pull/147

From:        "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:        09/13/2021
06:25 AM
Subject:        [EXTERNAL]
Re: [cu-dev] Concurrency 3.0 pulls ready for review: #38, #40, #46, #100,
#101, #35, #99
Sent by:        "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>

---

Hi Nathan,

 

Go ahead and merge.

 

Apologies of being a bit slow in responding recently I am in the middle of a house move and sale.

 

Steve

 

From:cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Nathan Rauh
Sent: 10 September 2021 23:12
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: Re: [cu-dev] Concurrency 3.0 pulls ready for review: #38, #40, #46, #100, #101, #35, #99

 

I'd like to start merging the 3 pulls from the list below that consist of copying interfaces over from MicroProfile.
Let me know if anyone is still in the process of reviewing these and would like more time, otherwise I'll go ahead and merge them in 5 days or so

Issue #40Completion stages backed by ManagedExecutorService
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/104

Issue #100ContextService methods for contextualizing individual dependent stage actions
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/138

Issue #101Completion stages backed by a ContextService
pull (also contains the commit for #100 which is a prereq due to references made in JavaDoc): https://github.com/eclipse-ee4j/concurrency-api/pull/139
commit that is unique to this pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/139/commits/ba9c817de5e47c4a32ee40c6bd46d97dcb3eea0e




From:        Nathan Rauh/Rochester/IBM
To:        "cu developer discussions" <cu-dev@xxxxxxxxxxx>
Date:        08/27/2021 01:26 PM
Subject:        Re: [EXTERNAL] Re: [cu-dev] Concurrency 3.0 pulls ready for review: #38, #40, #46, #100, #101, #143, #144

---

Adding 2 more pulls to the list needing review,

Issue #40Completion stages backed by ManagedExecutorService
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/104

Issue #100ContextService methods for contextualizing individual dependent stage actions
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/138

Issue #101Completion stages backed by a ContextService
pull (also contains the commit for #100 which is a prereq due to references made in JavaDoc): https://github.com/eclipse-ee4j/concurrency-api/pull/139
commit that is unique to this pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/139/commits/ba9c817de5e47c4a32ee40c6bd46d97dcb3eea0e

Issue #38Define Concurrency Resources Portably
This pull is the first step - getting the annotations defined with the most basic attributes.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/141

Issue #46Parallel Stream Support
The most I can see doing for this one is to have ManagedThreadFactory also implement ForkJoinWorkerThreadFactory.  Alternatively, we could do nothing and leave it to the user to implement something similar based on ContextService.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/140

Issue #35Java SE 8 Date and Time Support
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/143

Issue #99Cron-based Trigger
This builds on the Java SE Date/Time based trigger (#35 above) so it also includes the commit for it.
commit that is unique to this pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/144/commits/8cec1222b66ea6ff68a730d1923fc7355592efe2






From:        "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        "cu developer discussions" <cu-dev@xxxxxxxxxxx>
Date:        08/10/2021 06:52 AM
Subject:        [EXTERNAL] Re: [cu-dev] Concurrency 3.0 pulls ready for review: #38, #40, #46, #100, #101
Sent by:        "cu-dev" <cu-dev-bounces@xxxxxxxxxxx>

---

 

Hi,

 

I will get my team to review. I’m also trying to push to get more feedback and involvement from others through a number of JUG talks and Jakarta tech talks. I’d like to get together a team that is interested in driving this forward in the Jakarta EE 10 timeframe.

 

I think it would be good to also have a co-project lead so I don’t feel the burden to drive the specification falls to me. @Nathan would you be interested in being a co-project lead?

 

Steve

 

From:cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Nathan Rauh
Sent: 09 August 2021 22:31
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [cu-dev] Concurrency 3.0 pulls ready for review: #38, #40, #46, #100, #101

Now that we are at
a point where we can start making updates for Jakarta EE 10, could specification
participants review the 5 pulls for the Concurrency 3.0 planned items below
(whichever you are comfortable with reviewing) and make comments in them
regarding any changes that are needed or otherwise approve them for merging?
Thanks!

Issue #40Completion
stages backed by ManagedExecutorService
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/104

Issue #100ContextService
methods for contextualizing individual dependent stage actions
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/138

Issue #101Completion
stages backed by a ContextService
pull (also contains the commit for #100 which is a prereq due to references
made in JavaDoc): https://github.com/eclipse-ee4j/concurrency-api/pull/139
commit that is unique to this pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/139/commits/ba9c817de5e47c4a32ee40c6bd46d97dcb3eea0e

Issue #38Define
Concurrency Resources Portably
This pull is the first step - getting the annotations defined with the
most basic attributes.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/141

Issue #46Parallel
Stream Support
The most I can see doing for this one is to have ManagedThreadFactory also
implement ForkJoinWorkerThreadFactory.  Alternatively, we could do
nothing and leave it to the user to implement something similar based on
ContextService. 
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/140




From:        Nathan
Rauh/Rochester/IBM
To:        cu
developer discussions <cu-dev@xxxxxxxxxxx>
Date:        05/10/2021
04:29 PM
Subject:        Ready
for review: #38, #40, #46, #100, #101

---

In addition to the 3 pulls that I mentioned previously (forwarded) for bringing over MicroProfile API,
the following 2 pulls are also ready for review:


Issue #38Define Concurrency Resources Portably
This pull is the first step - getting the annotations defined with the most basic attributes.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/141


Issue #46Parallel Stream Support
The most I can see doing for this one is to have ManagedThreadFactory also implement ForkJoinWorkerThreadFactory.  Alternatively, we could do nothing and leave it to the user to implement something similar based on ContextService.
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/140


see below for 3 additional pulls to copy over MicroProfile API,

----- Forwarded by Nathan Rauh/Rochester/IBM on 05/10/2021 04:11 PM -----

From:        Nathan Rauh/Rochester/IBM
To:        cu developer discussions <cu-dev@xxxxxxxxxxx>
Date:        03/31/2021 10:11 AM
Subject:        Ready for review: #40, #100, #101 for transferring over MicroProfile API to Jakarta EE Concurrency 3.0

---

Given the amount of proposed content for Concurrency in Jakarta 10, I've started putting together pulls for the MicroProfile-related enhancements currently in the Milestone 3 list, starting with the ones for copying over API methods around CompletionStage/CompletableFuture.  The following 3 are ready to start reviewing now (I won't actually be merging anything until after the release plan is official, and of course pending approval from the community)

When reviewing these, it will be helpful to note that MicroProfile class ManagedExecutor is the equivalent of our ManagedExecutorService,
and MicroProfile class ThreadContext is the equivalent of our ContextService.

The method signatures themselves are an exact copy (which will be great for compatibility), except for the one place where MicroProfile's ManagedExecutor has a getThreadContext method that returns a ThreadContext, which is switched to ContextService. The intent behind the MicroProfile method here is so that threadContext/contextService.withContextCapture(completionStage/completableFuture) can create CompletionStage/CompletableFuture proxies that are backed by the ManagedExecutor.  But managedExecutor[Service].copy(completionStage/completableFuture) can already do that.  We can decide if the equivalent getContextService method is really wanted/needed here, and if not, I can remove it.  To start out with, I included it in the pull so that you have the opportunity to see what it would look like if we did include it. Please add your feedback on it in the review.  I would be happy with either outcome and will go with the majority on it.

Issue #40Completion stages backed by ManagedExecutorService
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/104

Issue #100ContextService methods for contextualizing individual dependent stage actions
pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/138

Issue #101Completion stages backed by a ContextService
pull (also contains the commit for #100 which is a prereq due to references made in JavaDoc): https://github.com/eclipse-ee4j/concurrency-api/pull/139
commit that is unique to this pull to review:
https://github.com/eclipse-ee4j/concurrency-api/pull/139/commits/ba9c817de5e47c4a32ee40c6bd46d97dcb3eea0e



_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

 _______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev