6 ms·

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

"Java application servers are dead" and since there's no alternative to Java application servers here's a solution I cooked up myself. Like I mentioned last time I appreciate an overview of modern Java practices but boy howdy I can't discern if this is clever trolling or a cheap way to make me read Part 3.

UK-AL 12y ago
I'm guessing tomcat.
philbarr 12y ago
I skimmed through Part 3 and it's basically saying that app servers are hard to deploy, maintain and dev against and you should be using Spring Boot or Dropwizard instead to create applications with the services you require.
- twic 12y ago
  I used Spring Boot the other day. It was really easy! Up until things just didn't work for no apparent reason, and neither the error messages nor documentation gave me any clues as to how to fix it. App servers have historically been hard to deploy, maintain and dev against. There has been a huge amount of progress in the last few years. Based on my experience, Java EE / Wildfly is actually easier to develop with than Spring Boot.
- john-waterwood 12y ago
  App servers like TomEE, JBoss and GlassFish are not hard to install at all, and certainly not to dev against. What's the author smoking? These servers are just unzip == fully installed things. We have them checked in and just deploy them automatically whenever there's a need for an update, pretty much as every other library out there. I wonder are we missing something or do people just wrongly think there's "something" difficult, where there's no need at all for things to be difficult?
- Patient0 12y ago
  Where did you find part 3?
  - philbarr 12y ago
    Ah my apologies, it's not actually part 3 it's the link he referenced when he talked about part 3: http://www.slideshare.net/ewolff/java-application-servers-are-dead http://www.slideshare.net/ewolff/java-application-servers-ar...
  - dafnap 12y ago
    Part 3 will be released toward the end of the week.
jacobheric 12y ago
I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.
- curun1r 12y ago
  Why is the Java community so enamored with creating Java-only solutions when general-purpose solutions work just as well (and often better)? There's no need to bundle everything up into an executable jar or war. It's much easier to write a Chef recipe to copy all the right files to the right places. And it's even easier to create a Docker container with the exploded war in its correct place. Both of those solutions don't rely on the clunky put-everything-inside-a-jar and the resulting need to write your own ClassLoader.
  - philbarr 12y ago
    Java - "run anywhere" (supposedly) Docker - "The Linux Container Engine" Think you've got your answer there.
    - curun1r 12y ago
      Docker is an option if you're deploying on Linux, which is what the majority of server deployments use these days. Chef works on the rest of the Unixes, including OS X. If you're deploying Java on a Windows server, you're doing it wrong. And the days of needing to use different development and production OSs are over...if you develop in Windows and deploy on some Unix variant, you should be using a VM. I'm still not buying ClassLoader contortions as being in any way justified to support the single deployable artifact requirement. It's just not necessary and can lead to many subtle and hard-to-track-down issues as well as introducing unnecessary performance overhead.
      - philbarr 12y ago
        > If you're deploying Java on a Windows server, you're doing it wrong. You're assuming you have control over what the customer's servers are.
bad_user 12y ago
> "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 12y ago
  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 12y ago
    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 12y ago
      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.

UK-AL 12y ago

I'm guessing tomcat.

philbarr 12y ago

I skimmed through Part 3 and it's basically saying that app servers are hard to deploy, maintain and dev against and you should be using Spring Boot or Dropwizard instead to create applications with the services you require.

twic 12y ago
I used Spring Boot the other day. It was really easy! Up until things just didn't work for no apparent reason, and neither the error messages nor documentation gave me any clues as to how to fix it. App servers have historically been hard to deploy, maintain and dev against. There has been a huge amount of progress in the last few years. Based on my experience, Java EE / Wildfly is actually easier to develop with than Spring Boot.
john-waterwood 12y ago
App servers like TomEE, JBoss and GlassFish are not hard to install at all, and certainly not to dev against. What's the author smoking? These servers are just unzip == fully installed things. We have them checked in and just deploy them automatically whenever there's a need for an update, pretty much as every other library out there. I wonder are we missing something or do people just wrongly think there's "something" difficult, where there's no need at all for things to be difficult?
Patient0 12y ago
Where did you find part 3?
- philbarr 12y ago
  Ah my apologies, it's not actually part 3 it's the link he referenced when he talked about part 3: http://www.slideshare.net/ewolff/java-application-servers-are-dead http://www.slideshare.net/ewolff/java-application-servers-ar...
- dafnap 12y ago
  Part 3 will be released toward the end of the week.

jacobheric 12y ago

I'd not go so far as to say it's trolling. Perhaps overly-dramatic hyperbole. As a Java developer, I do see a shift away from packaging up wars and deploying them to application servers. See Dropwizard or Spring Boot for examples of frameworks that prefer to run fat jars that serve http requests via embedded containers.

curun1r 12y ago
Why is the Java community so enamored with creating Java-only solutions when general-purpose solutions work just as well (and often better)? There's no need to bundle everything up into an executable jar or war. It's much easier to write a Chef recipe to copy all the right files to the right places. And it's even easier to create a Docker container with the exploded war in its correct place. Both of those solutions don't rely on the clunky put-everything-inside-a-jar and the resulting need to write your own ClassLoader.
- philbarr 12y ago
  Java - "run anywhere" (supposedly) Docker - "The Linux Container Engine" Think you've got your answer there.
  - curun1r 12y ago
    Docker is an option if you're deploying on Linux, which is what the majority of server deployments use these days. Chef works on the rest of the Unixes, including OS X. If you're deploying Java on a Windows server, you're doing it wrong. And the days of needing to use different development and production OSs are over...if you develop in Windows and deploy on some Unix variant, you should be using a VM. I'm still not buying ClassLoader contortions as being in any way justified to support the single deployable artifact requirement. It's just not necessary and can lead to many subtle and hard-to-track-down issues as well as introducing unnecessary performance overhead.
    - philbarr 12y ago
      > If you're deploying Java on a Windows server, you're doing it wrong. You're assuming you have control over what the customer's servers are.

bad_user 12y ago

> "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 12y ago
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 12y ago
  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 12y ago
    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.