|Re: [ee4j-community] Just for application servers?|
I definitely agree with Greg – app servers are a type of runtimes.
Runtimes can both be prepackaged or can be assembled during build time. As an example, Java itself (JRE) is also a runtime, and while it's mostly used as a prepackaged bundle, it's possible to bundle it with an app, and since Java 9 it's possible to use only separate components assembled at build time. With app servers, only the first option used to be possible but now you can also bundle some servers with an app as a runtime or even reuse just some components.
We should really target all usecases of JRE and extend it, therefore the best term is runtime or runtime extension, not just server.
On 16 October 2017 at 23:17, Adam Bien <abien@xxxxxxxxxxxxx> wrote:
But for both there are still package and deploy steps: App servers you have to package your application in a special way and then deploy to the appserver, while run times like docker/springboot you package the server into your image/jar and then deploy. Even with micro services, cloud lambdas or cloud functions, there are still package and deploy steps, it's just that the tooling makes it even more transparent, but the technical solution behind the scenes will be something above.
The way we use these terms for the Jetty project is that we say we can be deployed as a "traditional app server", meaning that there is a know set of services provided and your application(s) can be dropped into the webapps directory to be deployed. OR that Jetty can be used as a component of your runtime, either 3rd party (GAE, springboot, docker etc.) or directly embedded in your applications. We used to say don't deploy your application in jetty, deploy jetty in your application.
To me, App Servers are just a type of runtimes, just ones with a particular large and fixed set of services provided. So to use the term Runtime rather than App Server is good, as it implies additional flexibility of deployment options, while still adhering to standards/
Back to the top