For some reason, the vast majority of developers has accepted the browser as the operation system for their applications. While there are some good reasons for this, I never really bought into it. HTML5 has eliminated most of the pain point of web applications, but I still insist that most customers don’t really want to use a web application. We’ve taught them to accept to open the browser to do their daily work, but there are still quite a few disadvantages to this approach. The “old stagers” among you know how many obstacles we had to overcome before the browser became a really useful operation system for writing applications. Just for the fun of it, let’s start this article summarizing some of them:
- How to deal with the “back” and “forward” buttons in a web application?
- How to print a document from a web application? Most developers export documents to be printed as PDF files, but wouldn’t it be nice to be able to print documents without this detour?
- How to import an Excel file into your application?
- More generally speaking, web applications run in a sandbox preventing access to low-level resources such as your computer’s file system.
Spring Boot stirred up the Java world. Developers always put up stoically with slow server start-ups, long deployment times and difficult server configurations. Those times seem to come to an end. There’s only so much coffee you can drink during the breaks.
The disadvantage of Spring Boot is it uses Spring, excluding roughly half of the Java community. As far as I know you can’t use CDI on Spring Boot. Even if you were to find a way how to do it, it’s questionable if it’s wise to use two different dependency injection frameworks simultaneously.
So what about the JavaEE world? The TomEE team are currently exploring what needs to be done to implement a JavaEE counterpart to Spring Boot. These days Alex Soto published a surprisingly simple prototype (complete source code here).
At the moment it’s only a sketch which can run servlets and REST services. Spring Boot goes far beyond that: just think of the amount of effort that went into monitoring. Alex Soto’s prototype has a long way to go yet to become a real competitor. In any case he has announce to publish more source code soon on GitHub.
Be that as it may, even the current prototype can already be useful. In an earlier article (Application Servers are dead!) I’ve sketched how to embed Jetty or Tomcat in a JAR file. TomEE is much more complete. Embedded TomEE also brings CDI, EJBs, JSF and the rest of the JavaEE stack. Of course documentation is still sparse, but an adventurous developer should be able to implement a full-blown JavaEE application on the 70-lines prototype.
By the way, this isn’t the only project inspired by Spring Boot. After finishing the article I stumbled about a similar, less ambitious project. If you’re interested only in CDI and REST services, forseti may be worth a look. It’s a tiny project running on Jetty.
Alex Soto’s announcement
BeyondJava.net’s running copy of the source code
How to run JSF and PrimeFaces on Spring Boot
Application Servers are dead! (Sort of)
Recently I reported about Spring Boot (see Application Servers are dead! (Sort of)), an interesting approach to embed your application server into your application instead doing it the other way round.
However, Spring Boot is a fairly new technology, so the documentation is still work in progress. Most of the documentation is great, but there are still sentences like
Applications that are not already Spring applications might be convertible to a Spring Boot application, and the guidance above might help, but your mileage may vary.
Most JSF applications clearly fall into this category. So I’ve prepared a JSF template project to spare you some of the mileage. Currently there’s a simple simple PrimeFaces project and a more advanced project demonstrating Spring and JSF scopes.
To make things more interesting, I added Gradle and JSF custom scopes to the equation.
Recently it crossed my mind there’s something wrong with Java application servers. You know, our team is still using them the way they’re meant. The way they were originally meant. We’ve got many applications running on a common application server that’s managed centrally.
I’m told we’re one of the last companies to do so. These days, most companies dedicate an entire application server to a single application and put them in a virtual machine.
In other words, application servers have become part of the application. Originally, it was meant to be the other way round, and that’s why Eberhard Wolff claims application servers are dead. His JAX talk was a real eye-opener, by the way. He expressed the thoughts that ware already lingering in the subconscious part of my mind. As usual, I’ll mention a few key points of his talk in this post, plus a few thoughts of my own. If you’re interested in the entire talk, have a glance at his slides. He also published an article in the Java-Magazin 7.2014 (in German language, and as far as I know, only available in print).
So what’s wrong with the original idea of applications servers? Let me put the question differently: Have you ever seen an application server that runs out of the box, without being modified?