![\"embedded-java-server-300x229\"](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2014\/03\/embedded-java-server-300x229.png\")
<\/a> However, there is another school of thought which completely turns this model on its head.\u00a0 In this approach, Java applications are packaged for command-line execution like any normal app.\u00a0 Rather than being deployed to a container, an embedded container is deployed within the application itself!<\/p>\nThis is par for the course with many languages.\u00a0 The Django<\/a> framework for Python includes a bundled server for development and testing, while Ruby on Rails<\/a> comes with an embedded server that is used in production as well.\u00a0 The concept has even been around for awhile in Java, with Jetty<\/a> specializing in the embedded niche.\u00a0 However, this is far from the norm, and the de facto standard is still a WAR file that can be deployed to Tomcat<\/a>.<\/p>\n The buzz is growing, though.\u00a0 At last year\u2019s\u00a0DevNexus<\/a> conference, I went to a session by James Ward<\/a>, who at that time was a \u201cdeveloper evangelist\u201d at Heroku<\/a>.\u00a0 Bundling your own container is the recommended<\/a> approach for deploying apps to Heroku\u2019s cloud-based platform, and James is a big proponent<\/a>.<\/p>\n His session was specifically about the Play<\/a> framework for Java and Scala, which embeds Netty<\/a> in a manner similar to the Rails server.\u00a0 Unlike Grails<\/a>, which uses a Django-style server for development and then ships as a WAR file, Play is meant to use its own server all the way to production.\u00a0 James advocated this approach in all Java apps.<\/p>\n I normally use Eclipse in my own development environment, and point it at a local Tomcat instance for testing web apps.\u00a0 However, I wanted to support readers who were more comfortable using IntelliJ, Netbeans, or no IDE at all.\u00a0 So I decided to have my build script embed<\/em> a test server, so readers could run the examples without installing or configuring anything. My first goal was simply to launch a server from within my Maven build scripts, so the readers wouldn\u2019t have to install a server or integrate it into their IDE.\u00a0 I had seen this done before, and it was a simple matter of adding the Jetty Maven Plugin<\/a> to a project\u2019s POM.\u00a0 Readers should be able to build the example application and launch it in one step, with the command:<\/p>\n However, you have to crack open a Jetty JAR file to get a correct copy of this config file.\u00a0 First, you have to dig around your local Maven repo and figure out which<\/em> JAR file to crack open (it turns out to be jetty-webapp rather than jetty-server).\u00a0 Once you get a copy of the webdefault.xml file and toggle the useFileMappedBuffer setting, you have to save your copy somewhere in your project, and update your Maven POM to look there rather than inside the Jetty JAR:<\/p>\n Okay\u2026 a little more hassle than I was expecting, but I can deal with this.<\/p>\n I know that many Java developers hate Maven.\u00a0 So I wanted to provide a version of my book\u2019s example application built using Ant, to illustrate how the default concepts can be adapted.\u00a0 So, which line do I add to build.xml to make Ant use Jetty?<\/p>\n After you copy over the Jetty server JAR\u2019s, you need to manually add another JAR file<\/a> for the Ant integration.\u00a0 To my surprise, I discovered that the most recent supported version was Jetty 7, implementing the Servlet 2.5 spec that is almost eight years old<\/a>. This last chapter of my book talks about Hibernate Search applications running in a clustered server environment.\u00a0 The Maven plugin is purely single-instance, so I decided to write a small bootstrap class that would pro grammatically launch two Jetty instances on different ports.\u00a0 By structuring this class as a JUnit test, I could still have Maven launch it automatically like this: Eh, not so fast.\u00a0 My application\u2019s servlets, listeners, and RESTful services were not being registered at startup.\u00a0 After much more wasted research time, I discovered that there are different \u201cflavors\u201d<\/a> of Jetty available, with Servlet 3.0 features (such as annotations) enabled or disabled by default.<\/p>\n To be honest, I still don\u2019t completely understand how to tell the difference between \u201chightide\u201d and \u201cnon-hightide\u201d.\u00a0 All I can tell you is that I had to add this hunk of code to my bootstrap class in order to make annotations work:<\/p>\n So much simpler and more intuitive than dropping a WAR file in Tomcat\u2019s \/webapps folder, right?<\/p>\n With the book complete, I wanted a demo version of the example code pushed to\u00a0GitHub<\/a> and deployed to Heroku<\/a>.\u00a0 Theoretically, Heroku can run any application that you can run locally from the command-line.\u00a0 If Heroku finds a Maven POM, it will run mvn clean package, and then execute whatever startup command you have placed in a script named Procfile.<\/p>\n Eh, not so fast.\u00a0 If your application expects database connections (or anything else) to be registered as JNDI resources, then you are on your own.\u00a0 Heroku\u2019s bundled Tomcat runner doesn\u2019t support JNDI setup.\u00a0 Hmm\u2026 maybe this is why Heroku\u2019s vanilla servlet demo doesn\u2019t really do anything, and why the only demo app that does<\/em> do something is Spring-based instead.\u00a0 Now that I think about it, James Ward left Heroku to work for TypeSafe last year, and Heroku hasn\u2019t made a single update to their\u00a0Java site<\/a> since he left.\u00a0 Gulp.<\/p>\n Eh, still too fast.\u00a0 If you use JSTL taglibs in your JSP views (i.e. you live in the 21st century), then Jetty Runner is a mess<\/a> that puts you in classpath hell.\u00a0 When running it from the command-line, you need to pass parameters to Java for:<\/p>\n (*) You read that correctly.\u00a0 After all of this embedded nightmare, Heroku is actually still using a WAR file<\/em>!!!<\/p>\n My Heroku Profile ended up looking like this:<\/p>\n There is more than one classloader at work here, and this allows the Jetty Runner to load the JSTL\/taglib stuff from its classpath rather than the web app\u2019s classpath.<\/p>\n The only real advantage I gained was the ability to run a demo on Heroku.\u00a0 However, Java support from cloud providers is improving every day.\u00a0 Jelastic<\/a> lets you deploy normal WAR files to Tomcat 7 or GlassFish 3 right now.\u00a0 AppFog supports deployment to Tomcat 6<\/a>, with support for Tomcat 7<\/a> coming soon.\u00a0 I suspect that in the not-so-distant future, the idea of modifying<\/em> your apps for cloud deployment will be seen as an\u00a0anachronism.<\/p>\n So in a nutshell, it depends on the framework you\u2019re using.\u00a0 If embedded servers are baked-in, then they can be very cool.\u00a0 If they are duct taped-on, then they can be horrible.\u00a0 If I were writing Hibernate Search by Example<\/em> today, the example application build scripts would produce two things:\u00a0 a WAR file, and a Tomcat download link. Most server-side Java applications (e.g. web or service-oriented) are intended to run within a container.\u00a0 The traditional way to package these apps for distribution is to bundle them as a WAR file.\u00a0 This is nothing more than a ZIP archive with a standard directory layout, containing all of libraries and application-level dependencies needed at runtime.\u00a0 …<\/p>\n","protected":false},"author":540,"featured_media":112,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"class_list":["post-22798","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-java"],"yoast_head":"\nAn embedded adventure<\/h2>\n
<\/a>
\nI had at least a sip of the Kool-Aid.\u00a0 When I started writing my book, Hibernate Search by Example<\/em><\/a>, I wanted to keep its focus on Hibernate Search rather than any other frameworks or server issues.\u00a0 So I eschewed Spring, and wrote the book\u2019s example application using a vanilla Servlet 3.0 approach.<\/p>\n
\n <\/p>\nUsing an embedded server with Maven<\/h3>\n
mvn clean jetty:run<\/pre>\n
<\/a>Eh, not so fast. You\u2019re supposed to be able to make changes to your static content, and see the changes immediately take effect while the server is running.\u00a0 However, I ran into errors about my files being locked. After wasting some time on research, I discovered that Jetty\u2019s default settings do not play nice with Windows file locking.\u00a0 This can be fixed by toggling one property in one config file<\/a>.<plugin>\r\n <groupId>org.mortbay.jetty<\/groupId>\r\n <artifactId>jetty-maven-plugin<\/artifactId>\r\n <version>8.1.7.v20120910<\/version>\r\n <configuration>\r\n <webAppConfig>\r\n <defaultsDescriptor>${basedir}\/src\/main\/webapp\/WEB-INF\/webdefault.xml<\/defaultsDescriptor>\r\n <\/webAppConfig>\r\n <\/configuration>\r\n<\/plugin><\/pre>\nUsing an embedded server with other build systems<\/h3>\n
<\/a>Eh, not so fast.\u00a0 There is<\/em> Ant integration for Jetty<\/a>, but it is even more cumbersome than Maven.\u00a0 Even if you are using a dependency-management system such as Ivy, your Ant script can\u2019t download and manage the embedded server for you.\u00a0 Instead, you have to download a full standalone Jetty server, and manually copy bits and pieces of it into your project.\u00a0 Who doesn\u2019t want 6 megs of executable binaries committed into source control?<\/p>\n
\n
\nI see that they finally added Jetty 8 last month, but that didn\u2019t help me when I was writing the book last autumn.\u00a0 I had to re-write this version of my example app for Servlet 2.5 instead of 3.0, and was starting to wonder if this was really worth it.<\/p>\nUsing an embedded server from code
<\/a><\/h3>\n
\n <\/p>\nmvn clean compile war:exploded test<\/pre>\n
...\r\nmasterContext.setConfigurations(\r\nnew Configuration[] {\r\nnew WebInfConfiguration(),\r\nnew WebXmlConfiguration(),\r\nnew MetaInfConfiguration(),\r\nnew FragmentConfiguration(),\r\nnew EnvConfiguration(),\r\nnew PlusConfiguration(),\r\nnew AnnotationConfiguration(),\r\nnew JettyWebXmlConfiguration(),\r\nnew TagLibConfiguration()\r\n}\r\n);\r\n...<\/pre>\nUsing an embedded server from the console and the cloud<\/h3>\n
<\/a>My programmatic Jetty launcher worked fine within the context of a Maven run.\u00a0 However, Maven was managing my classpath dependencies at test time, and now I need Jetty available without<\/em> that help.\u00a0 Heroku\u2019s recommended approach<\/a>,\u00a0 used in their demo Java applications<\/a>, is to bundle your app with a one-file version of Tomcat.\u00a0 Awesome, I\u2019m more familiar with Tomcat anyway!<\/p>\n<\/a>
\nDon\u2019t worry, because there is a similar one-file Jetty Runner<\/a>, and it does<\/em> let you pass JNDI settings as command-line parameters.\u00a0 Besides, we\u2019ve invested a lot of time solving all the problems with embedded Jetty already!<\/p>\n\n
web: java $JAVA_OPTS -jar target\/dependency\/jetty-runner-8.1.7.v20120910.jar --lib target\/hibernate-search-demo-0.0.1-SNAPSHOT\/WEB-INF\/lib --port $PORT --jdbc org.apache.commons.dbcp.BasicDataSource \"url=jdbc:h2:mem:vaporware;DB_CLOSE_DELAY=-1\" \"jdbc\/vaporwareDB\" target\/*.war<\/pre>\n
Conclusion<\/h2>\n
<\/a>There is nothing inherently wrong with the embedded server concept, when it is baked-in to a framework from the outset.\u00a0 Writing Play applications is a pleasure, and they are almost trivial to deploy on Heroku.\u00a0 At my day job, I use a Spring-based commerce package called hybris<\/a>, whose extensive build system bundles a Tomcat server into your app.\u00a0 As long as you don\u2019t need to customize the build scripts too much, this works fine.<\/p>\n<\/a>On the other hand, the concept is just too fragile and brittle for wide general-purpose use.\u00a0 Duct taping an embedded server onto a normal Java application is pure pain.\u00a0 You might be able to cling to the safety of someone else\u2019s working example,\u00a0 but the moment your app does anything<\/em> different, you are on your own to fix the breakage.\u00a0 Take my embedded adventure above, and contrast it with the \u201chassle\u201d of using Tomcat:<\/p>\n\n
\n <\/p>\n