| Re: [ee4j-community] Approach to Reactive in Jakarta EE |
ClementJames, if you are still thinking about writing these guidelines, you can count on my help.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.(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,
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> 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).-RyanOn Mar 8, 2018, at 6:08 AM, James Roper <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_______________________________________________
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
_______________________________________________
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
_______________________________________________
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