| Re: [ee4j-community] Approach to Reactive in Jakarta EE |
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
or, via email, send a message with subject or body 'help' to
ee4j-community-request@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Re: Approach to Reactive in Jakarta EE (Steve Millidge (Payara))
------------------------------------------------------------ ----------
Message: 1
Date: Tue, 20 Mar 2018 14:36:38 +0000
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Approach to Reactive in Jakarta EE
Message-ID:
<HE1PR03MB1787911C04271FE25E918F3A91AB0@HE1PR03MB1787. >eurprd03.prod.outlook.com
Content-Type: text/plain; charset="utf-8"
OK in the sense of some guidelines for consistency perhaps that is correct and the working group could do it under one of the committees or if this is technical guidelines to be recommended to EE4J projects these could be worked an at the EE4J PMC level and held in the top level project. If you are going to produce some code then a project would be more appropriate. Either one of the existing projects that is the most appropriate or a new project.
I was also making it known that it is possible to create EE4J projects without involvement of the Jakarta EE WG ?
Steve
From: ee4j-community-bounces@eclipse.org <ee4j-community-bounces@eclipse.org > On Behalf Of James Roper
Sent: 20 March 2018 09:42
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Approach to Reactive in Jakarta EE
Hi Steve,
We're talking about writing one page of best practices that will apply to many projects. I don't expect that the page will be more than 1000 words long. Does that really warrant its own project? Creating this document feels like just a regular every day task for the Jakarta EE working group to do. If every time someone wants to write a single page of documentation they have to go through the whole Eclipse project proposal process, something seems very wrong.
Regards,
James
On 20 March 2018 at 20:27, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx<mailto:steve.millidge@payara. fish >> wrote:
Hi
AFAIK you can follow the Eclipse Development Process https://www.eclipse.org/projects/dev_process/#6_2_ and submit a project proposal to create a project under EE4J, this is the standard process. If later a project graduates to become part of the JakartaEE specification then the working group will become involved. Until that point just put together a project proposal under EE4J and the PMC will consider it.Project_Lifecycle
Steve
From: ee4j-community-bounces@eclipse.org <mailto:ee4j-community-bounces@xxxxxxxxxxx > <ee4j-community-bounces@eclipse.org <mailto:ee4j-community-bounces@xxxxxxxxxxx >> On Behalf Of Greg Wilkins
Sent: 20 March 2018 05:38
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >>
Subject: Re: [ee4j-community] Approach to Reactive in Jakarta EE
James,
I've not tuned into the process discussions here, so I'll let others decide if that is appropriate.
But if there is no process yet defined, then using collaborate tools to write a document is basically the JEP process for openJDK and works for me.... It's better than not getting something written down.
cheers
On 20 March 2018 at 15:32, James Roper <james@xxxxxxxxxxxxx<mailto:james@xxxxxxxxxxxxx >> wrote:
Hi Greg,
Perhaps then we could create a ReactiveGuidelines.md in this repo:
https://github.com/eclipse-ee4j/ee4j
I could start with making a pull request with a basic skeleton, and then we can collaborate from there?
Cheers,
James
On 20 March 2018 at 15:23, Greg Wilkins <gregw@xxxxxxxxxxx<mailto:gregw@xxxxxxxxxxx >> wrote:
James,
my preference is that it stays in an eclipse repo..... We are struggling already with our efforts to stay in touch (let alone contribute to) both the EE4J and reactive efforts, so the creation of yet another repository to monitor is just going to increase the barrier for participation (at least for the jetty project).
However, I do agree with the approach of using the github tools to collaborate on a README to scope out ideas etc.
cheers
On 20 March 2018 at 11:42, James Roper <james@xxxxxxxxxxxxx<mailto:james@xxxxxxxxxxxxx >> wrote:
Hi Clement,
My mail client decided that your email was a new thread, so I've copied your email below to include it in this thread.
I'm ready to make a start on this immediately. At some point in future, I'm guessing there would be a clear way for this to get going, it would come under the umbrella of some committee, a place for the effort to live might be decided, etc, but we're not there yet obviously, committees aren't appointed/elected yet. I propose that we don't let that hinder us, and instead we create a GitHub repo (doesn't have to be in the Eclipse foundation), and work on the guidelines in a README there. We can use GitHub as a place to discuss the minutiae, and use this mailing list/email thread to discuss broader issues, with regular updates posted here to keep the community informed. At some point in future, when the right structures are in place, the guidelines can be officially adopted (probably with further changes after review) by the Jakarta EE working group (or whichever committee is relevant).
Does anyone have any objections to that approach?
Regards,
James
On 19 March 2018 at 00:57, clement escoffier <clement.escoffier@xxxxxxxxx<mailto:clement.escoffier@ gmail.com >> wrote:
(I tried to reply to an existing thread that happened before I subscribed to this list, hopefully, it won't mess up everything, especially archives)
Hello,
I think that writing some kind of guidelines answering the questions listed by James would be greatly beneficial. In a first version, it could focus on the API (Reactive Streams, CompletionStage...). Topics such as execution model, the relation with CDI can also be covered, maybe in a second step.
James, if you are still thinking about writing these guidelines, you can count on my help.
Clement
On 9 March 2018 at 11:46, Jesse McConnell <jesse.mcconnell@xxxxxxxxx<mailto:jesse.mcconnell@gmail. com >> wrote:
Jetty is interested as well. Simone Bordet has implemented a few different approaches over the last couple of years on top of Jetty and it would be nice to see a 'good' standard emerge.
On Mar 8, 2018 6:17 PM, "Ryan Cuprak" <rcuprak@xxxxxxxxx<mailto:rcuprak@xxxxxxxxx >> wrote:
I vote for standardizing reactive programming in Jakarta EE.
I have been a fan of Vert.x and would like to see something like that in the platform. It would definitely make justifying its use at work easier if it was part of Java EE (reduces approvals needed).
-Ryan
On Mar 8, 2018, at 6:08 AM, James Roper <james@xxxxxxxxxxxxx<mailto:james@xxxxxxxxxxxxx >> wrote:
Hi all,
There are a number of different efforts in different Jakarta EE specs to provide support for reactive features. As many of you may know, I myself have been talking to and investigating a number of different places where Reactive Streams could be useful in Jakarta EE, but these efforts aren't limited to my work - JAX RS 2.1 introduces reactive features in the client, JSR 356 WebSockets support asynchronous streaming of messages, Servlet 3.0 introduced support for asynchronous sending of responses while Servlet 3.1 introduced asynchronous streaming IO. I've also talked to some spec implementers, such as CDI, who are interested in reactive features but aren't sure where to start.
While it's great that this innovation is happening, there is a risk that all these efforts, being done in isolation, will produce a platform that doesn't integrate well with itself, and feels disjointed. For example, if messaging uses an asynchronous streaming API that is incompatible with the streaming offered by the WebSocket spec, then how are people meant to use these two APIs together? If the streaming API for response bodies offered by the JAX RS client is incompatible with the streaming API for response bodies offered by the Servlet spec, how are people meant to use these two APIs together?
So I'd like to propose that we start an intentional effort of formalising an approach to reactive in Jakarta EE. What I think we should have answered is questions like:
* When should an API use CompletionStage?
* When should an API use Reactive Streams?
* How should Reactive Streams based APIs be offered?
* When should an API introduce its own mechanism/API for handling asynchronous data flows?
* How should CDI context be addressed when much of the business logic of an application is moved to callbacks executed by unmanaged threads?
I don't know what such an effort would look like in practice - the product might be a wiki page, or perhaps a document with code samples on GitHub. Maybe a dedicated mailing list is needed, or perhaps discussion can be had on another mailing list.
Does this resonate with anyone? It's perhaps not on front of everyones minds right now, but it's something that needs to be addressed before mass adoption of reactive features in Jakarta EE happens, and as there are efforts currently in place, the sooner its addressed, the better.
Regards,
James
--
James Roper
Senior Octonaut
Lightbend<https://www.lightbend.com/ > ? Build reactive apps!
Twitter: @jroper<https://twitter.com/jroper >
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
--
James Roper
Senior Octonaut
Lightbend<https://www.lightbend.com/ > ? Build reactive apps!
Twitter: @jroper<https://twitter.com/jroper >
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
--
Greg Wilkins <gregw@xxxxxxxxxxx<mailto:gregw@xxxxxxxxxxx >> CTO http://webtide.com
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
--
James Roper
Senior Octonaut
Lightbend<https://www.lightbend.com/ > ? Build reactive apps!
Twitter: @jroper<https://twitter.com/jroper >
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
--
Greg Wilkins <gregw@xxxxxxxxxxx<mailto:gregw@xxxxxxxxxxx >> CTO http://webtide.com
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
--
James Roper
Senior Octonaut
Lightbend<https://www.lightbend.com/ > ? Build reactive apps!
Twitter: @jroper<https://twitter.com/jroper >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180320/9bb0d76a/attachment. html
------------------------------
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
End of ee4j-community Digest, Vol 7, Issue 68
*********************************************