[bad_user]

> "Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself.

The alternative are servlet containers, like Jetty or Tomcat. Jetty for example is very popular and really good and can be easily embedded inside an app for single JAR deployments, which is an awesome way to deploy an app btw.

[benjaminpv]

Fair enough, it's a matter of terminology then, I guess?

Generally I think of Tomcat as being as much of an application server as something like JBoss is.

Granted, JBoss/Wildfly has a lot more enterprise-y features, but they both 'serve' web 'applications.'

[pron]

I was talking about app/servlet containers (Tomcat, JBoss, WebSphere, etc.), vs embedded, single-app servers (Jetty, embedded Tomcat, and Dropwizard, which is essentially Jetty+Jersey+added goodies)

[bad_user]

Dropwizard is a framework that delegates to Jetty the responsibility of serving requests by default, but you can host a Dropwizard app on whatever server you like.

In Java terminology, "application server" has actually started to mean servers capable of the full Java EE stack, which really means EJB and JMS. Jetty is not capable of those. Tomcat from what I know is not capable of those either. Both are targeting first and foremost the servlets API, which is pretty light and arguably good (well, at least since the latest Servlets 3.1, which finally adds asynchronous readings of requests).

Servlets is the piece of Java EE that I actually like - for everything else, there are third-party libraries and frameworks - though I've been working lately with Play framework, which comes with its own server and deployments on top of servlet containers is not officially supported, but that was primarily because it is a fully async framework and Servlets < 3.1 was inadequate for that, so things might change.

I also prefer embedding and the deployment of fat JARs to WARs. Makes things easier - a WAR implies that you need a management interface and a configured instance of your production server. A JAR implies that everything comes bundled in, configuration and all and you only have to copy and execute it directly, plus with embedding you have more fine-grained control. When I was using an embedded Jetty for example, a fine-tuned the shit out of its thread and connection pools, all from code.

[john-waterwood]

Thinking Java EE is primarily about EJB and JMS is pretty old school.

These days CDI is the centrepiece of Java EE, along with services like Interceptors and Bean Validation. JPA, JSF and JAX-RS also play pretty important roles, which are all things you don't find by default in Tomcat.

Actually, nearly every time I see people using Tomcat they add many of the things mentioned above. You might as well start with TomEE then and work from there.

[bad_user]

CDI, Interceptors, Bean Validation, JPA, JSF - all of them suck.

JAX-RS is the only thing OK-ish in the list you mentioned, unfortunately its design that ignored asynchronicity has been shortsighted (heard that it got fixed in 2.0, but apparently they also added junk).