AVISO DE CONFIDENCIALIDAD
DE CORREO ELECTRÓNICOEsta comunicación contiene
información que es confidencial y también puede contener información privilegiada.
Es para uso exclusivo del destinatario. Si usted no es el destinatario
tenga en cuenta que cualquier distribución, copia o uso de esta comunicación
o la información que contiene está estrictamente prohibida. Si usted ha
recibido esta comunicación por error por favor notifíquelo por correo electrónico(info@xxxxxxxxxx)
o por teléfono (+54 11 3249 7503)This communication contains
information that is confidential and may also be privileged. It is for
the exclusive use of the recipient. If you are not the intended note that
any distribution, copying or use of this communication or the information
it contains is strictly prohibited. If you have received this communication
in error please notify us by email(info@xxxxxxxxxx)
or phone (+54 11 3249 7503)
On Tue, Mar 20, 2018 at 6:42 AM, James Roper <james@xxxxxxxxxxxxx>
wrote:
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>
wrote:
Hi
AFAIK you can follow the Eclipse Development Process https://www.eclipse.org/projects/dev_process/#6_2_Project_Lifecycleand 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.
Steve
From: ee4j-community-bounces@xxxxxxxxxxx<ee4j-community-bounces@xxxxxxxxxxx>
On Behalf Of Greg Wilkins
Sent: 20 March 2018 05:38
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
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>
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>
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>
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> 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>
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>
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>
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 – Build
reactive apps!
Twitter: @jroper
_______________________________________________
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
--
James Roper
Senior Octonaut
Lightbend – Build
reactive apps!
Twitter: @jroper
_______________________________________________
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
--
Greg Wilkins <gregw@xxxxxxxxxxx>
CTO http://webtide.com
_______________________________________________
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
--
James Roper
Senior Octonaut
Lightbend – Build
reactive apps!
Twitter: @jroper
_______________________________________________
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
--
Greg Wilkins <gregw@xxxxxxxxxxx>
CTO http://webtide.com
_______________________________________________
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
--
James Roper
Senior Octonaut
Lightbend – Build
reactive apps!
Twitter: @jroper
_______________________________________________
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://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_ee4j-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=wq8uzoJ8hUBu1VQAqeXDRT4N7V3kssZmsRCDCi3ccX8&m=wnxtXzYJX00FgP4MNiaoPQLYY-g1g4t11-CDHC774OM&s=1_5Ffr6I8EjtPQI277wXsF5rWgbVY6WHepLNvWRTQxQ&e=