| Re: [ee4j-community] Just for application servers? |
Jean, Good Point. Especially with Oracle itself going into a completely different separate direction (Fn, the Serverless Framework and runtime for the Cloud) maybe the term application Servers is not ideal. Container maybe or Runtime, as Long as it is not confused with Things like Docker (Container) Werner From: ee4j-community-request@xxxxxxxxxxx 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@xxxxxxxxxxx You can reach the person managing the list at ee4j-community-owner@xxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of ee4j-community digest..." Today's Topics: 1. Just for application servers? (Jean-Francois James) 2. Re: Just for application servers? (Martijn Verburg) 3. Re: Just for application servers? (Mark Little) 4. Re: Just for application servers? (Mike Milinkovich) ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Oct 2017 15:29:46 +0200 From: Jean-Francois James <jefrajames@xxxxxxxxx> To: ee4j-community@xxxxxxxxxxx Subject: [ee4j-community] Just for application servers? Message-ID: <CAPXKBed0C6erT26NjDUgAwWWKj+2D4DDFJ8mGo8ER4eqxUYJmw@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8" First off, I want to thank all of you who've started working on EE4J. What an exciting and huge challenge! Reading the draft charter, I've the feeling that speaking about "APIs for application servers" is a bit restrictive. The present is focused on microservices and containers, serverless may be the future and in this context "Application servers" in general do not look that future-proof. By saying that, I don't want to re-start the technical debate "Thin war vs Uber jar". It is just a matter of communication and intention. May be we should speak about "standard APIs for modern Java applications". A good illustration of what I mean here is RedHat Wildfly Swarm wich enables to run the same applications in a server or standalone mode. Jean-Fran?ois James -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171011/94549c9b/attachment.html> ------------------------------ Message: 2 Date: Wed, 11 Oct 2017 13:31:34 +0000 From: Martijn Verburg <martijnverburg@xxxxxxxxx> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] Just for application servers? Message-ID: <CAP7YuAR6yVyYXV_fA-zZUDd02CSZfSyExwOxbkGoN241+pUZZg@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8" Hi Jean, A number of people have raised similar concerns so thank you! I strongly suspect the project charter will be amended accordingly On Wed, 11 Oct 2017 at 14:29, Jean-Francois James <jefrajames@xxxxxxxxx> wrote: > First off, I want to thank all of you who've started working on EE4J. What > an exciting and huge challenge! > > > > Reading the draft charter, I've the feeling that speaking about "APIs for > application servers" is a bit restrictive. The present is focused on > microservices and containers, serverless may be the future and in this > context "Application servers" in general do not look that future-proof. > > > > By saying that, I don't want to re-start the technical debate "Thin war vs > Uber jar". It is just a matter of communication and intention. May be we > should speak about "standard APIs for modern Java applications". > > > > A good illustration of what I mean here is RedHat Wildfly Swarm wich > enables to run the same applications in a server or standalone mode. > > > Jean-Fran?ois 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 > -- Cheers, Martijn (Sent from Gmail Mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171011/7c1479f0/attachment.html> ------------------------------ Message: 3 Date: Wed, 11 Oct 2017 06:33:05 -0700 From: Mark Little <mlittle@xxxxxxxxxx> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx> Subject: Re: [ee4j-community] Just for application servers? Message-ID: <CAEcX1=uQQe-qFZB9njB3LPHry9xZoc-Kz60eWLvmJ53DbHougw@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="UTF-8" Yes it will be. On Wed, Oct 11, 2017 at 6:31 AM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote: > Hi Jean, > > A number of people have raised similar concerns so thank you! I strongly > suspect the project charter will be amended accordingly > > On Wed, 11 Oct 2017 at 14:29, Jean-Francois James <jefrajames@xxxxxxxxx> > wrote: >> >> First off, I want to thank all of you who've started working on EE4J. What >> an exciting and huge challenge! >> >> >> >> Reading the draft charter, I've the feeling that speaking about "APIs for >> application servers" is a bit restrictive. The present is focused on >> microservices and containers, serverless may be the future and in this >> context "Application servers" in general do not look that future-proof. >> >> >> >> By saying that, I don't want to re-start the technical debate "Thin war vs >> Uber jar". It is just a matter of communication and intention. May be we >> should speak about "standard APIs for modern Java applications". >> >> >> >> A good illustration of what I mean here is RedHat Wildfly Swarm wich >> enables to run the same applications in a server or standalone mode. >> >> >> >> Jean-Fran?ois 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 > > -- > Cheers, Martijn (Sent from Gmail Mobile) > > _______________________________________________ > 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 > ------------------------------ Message: 4 Date: Wed, 11 Oct 2017 09:34:10 -0400 From: Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> To: ee4j-community@xxxxxxxxxxx Subject: Re: [ee4j-community] Just for application servers? Message-ID: <dca9aea1-81c2-5cd3-4258-f0f067eb7566@xxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 2017-10-11 9:31 AM, Martijn Verburg wrote: > A number of people have raised similar concerns so thank you! I > strongly suspect the project charter will be amended accordingly > > On Wed, 11 Oct 2017 at 14:29, Jean-Francois James > <jefrajames@xxxxxxxxx <mailto:jefrajames@xxxxxxxxx>> wrote: > > Reading the draft charter, I've the feeling that speaking > about?"APIs for application servers" is a bit restrictive. The > present is focused on microservices and containers, serverless may > be the future and in this context "Application servers" in general > do not look that future-proof. > Agreed. A revision of the charter that includes many of this helpful suggestions will be posted in a day or so. -- Mike Milinkovich mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx (m) +1.613.220.3223 EclipseCon Europe 2017 <http://www.eclipsecon.org/europe2017> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20171011/82a314f5/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 2, Issue 71 ********************************************* |