and off you go. No Application server. No classpath.<\/p>\n
This approach has been popularised by the microservices architectural style and frameworks like Springboot<\/a>.<\/p>\n \u201cIn short, the microservice architectural style<\/a> is an approach to developing a single application<\/strong> as a suite of small services<\/strong>, each running in its own process<\/strong> and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable<\/strong> by fully automated deployment machinery\u201d<\/em>.<\/p>\n Having a bunch of executable jar files tick all the boxes above.<\/p>\n The fatjar concept has also been available in Java EE for a while now. All the lightweight application servers have a \u201cMicro\u201d option:<\/p>\n There are many pros to having a fatjar deployment. However, there are some cons as well.<\/p>\n Docker has taken the microservices approach a level deeper and allow you to isolate on OS level. This means, building separate jar files become less relevant as you will be building separate Docker images.<\/p>\n Building a fat jar to be deployed as a Docker image is actually slower and heavier than a thin war. You typically layer you Docker images:<\/p>\n (above: your final layer in the fatjar option is much heavier than the thinwar option, as it includes the embedded application server)<\/p>\n Traditional Websphere is big, slow, expensive and difficult to install. Not something you would use to build Microservices with. IBM is a fairly late entry to the lightweight application server solutions with Websphere Liberty<\/a>, of which the core has been open-sourced recently under OpenLiberty<\/a>.<\/p>\n But this late entry might be the reason why they have done certain things right and very clean. The way that you can only load the parts that you need with features, and how you can extend the server with your own features, is awesome. Even though other application servers are also doing some modularity with OSGi (or JBoss Modules), it\u2019s just easier with Liberty. For Liberty, including Microprofile<\/a> is just another feature. Other application servers have added MicroProfile to their fatjar (\u201cMicro\u201d) distributions, and even though I believe it\u2019s possible to also add it to the full application server release, it\u2019s not easy to do.<\/p>\n The other cool thing is how you can very easily decide the deployment model only at deploy time. So you can have the best of all worlds. You can develop against a full application server with the thinwar model to get a quick turnaround. When building, you can assemble a fatjar, thinwar, docker image or all of them. What you develop against stays the same.<\/p>\n I have created a simple application to demonstrate these deployment options. (Code is available in GitHub<\/a>)<\/p>\n I did not want to build a basic \u201cHello world\u201d, as I wanted to include some of the MicroProfile features, so this is a \u201cQuote of the Day\u201d app. It uses a factory to load a quote provider (there is only one for now). The current provider gets and caches a quote from forismatic.com<\/a>. I use the MicroProfile Configuration API<\/a> to configure things like the HTTP Proxy, the URL and the provider to load. I use the MicroProfile Fault Tolerance API<\/a> to make sure we survive when the provider source is not available.<\/p>\n Configuration on OpenLiberty is also very clean. This makes it easy to include the configuration in your project. Using maven resource filtering, you can also extract certain variables to your build. Below the important parts of my src\/main\/liberty\/config\/server.xml<\/strong><\/p>\n For now we just include the umbrella features for Java EE and Microprofile. A bit later we can fine tune that to reduce the memory footprint.<\/p>\n The All variables in the (You can see the full So when we do a I am using maven profiles<\/a> to allow me to select, at build time, which deployment option I want:<\/p>\n In the This option follows the same development cycle than a fatjar cycle (although it does not create a jar file). If you do a Of course using an IDE like Netbeans (or any other IDE) this is actually just a button you click:<\/p>\n With this option we want to install, configure and start the server, and then deploy a thin war continuously as we write code. We still install and configure the server from scratch every time we start the server, just not on every deploy.<\/p>\n You can now deploy the thinwar continuously:<\/p>\n Stopping the server is also very easy:<\/p>\n It\u2019s very easy to create a fatjar distribution with In my target directory I now have an executable (fat)jar file that I can start with: In all the above mentioned And that should give you a quote of the day:<\/p>\n To start off I used the umbrella Using 50,691 kbytes<\/strong><\/p>\n You can change the Again using 30,198 kbytes<\/strong><\/p>\n Ideally you would also fine-tune the We can argue whether it\u2019s better to do fatjars vs thinwars and the pros and cons of having an application server, or not. However, not having to make this decision when we start developing (ie. download the micro distribution or the full distribution) but only when we build, allows for more options. Maybe it\u2019s possible to do that with the other application servers, but OpenLiberty made it easy.<\/p>\n Also read this great blogs from Pavel Pscheidl<\/a><\/p>\n and watch this video from Adam Bien<\/a><\/p>\nJava EE<\/h2>\n
\n
\n
Docker<\/h2>\n
![\"\"](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2017\/12\/docker_layering.png\")
<\/a><\/p>\nOpenLiberty is cool !<\/h2>\n
OpenLiberty with MicroProfile example<\/h2>\n
Configuring OpenLiberty<\/h3>\n
server.xml<\/code> (you can see the full one in github<\/a>)<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<server description=\"${project.build.finalName}\">\r\n\r\n <featureManager>\r\n <feature>javaee-7.0<\/feature>\r\n <feature>microProfile-1.2<\/feature>\r\n <\/featureManager>\r\n\r\n <httpEndpoint id=\"defaultHttpEndpoint\"\r\n httpPort=\"${httpPort}\"\r\n httpsPort=\"${httpsPort}\"\/>\r\n\r\n <application location=\"${project.build.directory}\/${project.build.finalName}.war\"\/>\r\n\r\n <logging traceSpecification=\"${log.name}.*=${log.level}\"\/>\r\n\r\n<\/server><\/pre>\n${httpPort}<\/code> and ${httpsPort}<\/code> will actually come from bootstrap.properties<\/a> that we create with the liberty maven plugin<\/a>.<\/p>\nserver.xml<\/code>, including ${project.build.directory}<\/code> and ${project.build.finalName}<\/code> will be replaced when we build with this resource filtering in the pom.xml:<\/p>\n<build>\r\n <finalName>${project.artifactId}<\/finalName>\r\n <resources>\r\n <resource>\r\n <directory>${basedir}\/src\/main\/liberty\/config<\/directory>\r\n <targetPath>${project.build.directory}<\/targetPath>\r\n <filtering>true<\/filtering>\r\n <includes>\r\n <include>server.xml<\/include>\r\n <\/includes>\r\n <\/resource>\r\n <\/resources>\r\n<\/build><\/pre>\npom.xml<\/code> in github<\/a>)<\/p>\nmvn clean install<\/code> the server.xml<\/code> will be copied to the target directory with the variables replaced.<\/p>\nDeployment options<\/h3>\n
<build><\/code> of pom.xml<\/a><\/p>\n<plugins>\r\n <plugin>\r\n <groupId>net.wasdev.wlp.maven.plugins<\/groupId>\r\n <artifactId>liberty-maven-plugin<\/artifactId>\r\n <version>${openliberty.maven.version}<\/version>\r\n\r\n <configuration>\r\n <assemblyArtifact>\r\n <groupId>io.openliberty<\/groupId>\r\n <artifactId>openliberty-runtime<\/artifactId>\r\n <version>${openliberty.version}<\/version>\r\n <type>zip<\/type>\r\n <\/assemblyArtifact>\r\n <\/configuration>\r\n <\/plugin>\r\n<\/plugins><\/pre>\nOn the fly option<\/h2>\n
mvn clean install -Pfatjar<\/code>, it will install, configure (from server.xml<\/code>) and start a server in the foreground. In other words, the mvn process does not finish, as the server start is part of the mvn process. To stop the server you need to ctrl-c<\/code> the process.<\/p>\n<profile>\r\n <id>fatjar<\/id>\r\n <activation>\r\n <property>\r\n <name>fatjar<\/name>\r\n <\/property>\r\n <\/activation>\r\n <build>\r\n <plugins>\r\n <plugin>\r\n <groupId>net.wasdev.wlp.maven.plugins<\/groupId>\r\n <artifactId>liberty-maven-plugin<\/artifactId>\r\n\r\n <executions>\r\n <execution>\r\n <phase>install<\/phase>\r\n <goals>\r\n <goal>install-server<\/goal>\r\n <goal>create-server<\/goal>\r\n <goal>run-server<\/goal> \r\n <\/goals>\r\n\r\n <configuration>\r\n <configFile>${project.build.directory}\/server.xml<\/configFile>\r\n <bootstrapProperties>\r\n <httpPort>${openliberty.http.port}<\/httpPort>\r\n <httpsPort>${openliberty.https.port}<\/httpsPort>\r\n <\/bootstrapProperties>\r\n <jvmOptions>\r\n <param>-Xmx${openliberty.Xmx}<\/param>\r\n <\/jvmOptions>\r\n <\/configuration>\r\n <\/execution>\r\n <\/executions>\r\n <\/plugin>\r\n\r\n <\/plugins>\r\n <\/build>\r\n <\/profile><\/pre>\n![\"\"](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2017\/12\/netbeans.png\")
<\/a><\/p>\nFull application server option:<\/h2>\n
mvn clean install -Pstart-liberty<\/code> will install, configure (from server.xml<\/code>) and start a liberty server in \/tmp<\/code> folder:<\/p>\n<profile>\r\n <id>start-liberty<\/id>\r\n <activation>\r\n <property>\r\n <name>start-liberty<\/name>\r\n <\/property>\r\n <\/activation>\r\n <build>\r\n\r\n <plugins>\r\n <plugin>\r\n <groupId>net.wasdev.wlp.maven.plugins<\/groupId>\r\n <artifactId>liberty-maven-plugin<\/artifactId>\r\n\r\n <executions>\r\n\r\n <execution>\r\n <id>1<\/id>\r\n <phase>pre-integration-test<\/phase>\r\n <goals>\r\n <goal>install-server<\/goal>\r\n <\/goals>\r\n <configuration>\r\n <assemblyInstallDirectory>${openliberty.installDir}<\/assemblyInstallDirectory>\r\n <\/configuration>\r\n <\/execution>\r\n\r\n <execution>\r\n <id>2<\/id>\r\n <phase>pre-integration-test<\/phase>\r\n <goals>\r\n <goal>create-server<\/goal>\r\n <goal>start-server<\/goal>\r\n <\/goals>\r\n <configuration>\r\n <installDirectory>${openliberty.installDir}\/wlp<\/installDirectory>\r\n <serverName>${project.artifactId}<\/serverName>\r\n <configFile>${project.build.directory}\/server.xml<\/configFile>\r\n <bootstrapProperties>\r\n <httpPort>${openliberty.http.port}<\/httpPort>\r\n <httpsPort>${openliberty.https.port}<\/httpsPort>\r\n <\/bootstrapProperties> \r\n <jvmOptions>\r\n <param>-Xmx${openliberty.Xmx}<\/param>\r\n <\/jvmOptions>\r\n <\/configuration>\r\n <\/execution>\r\n\r\n <\/executions>\r\n <\/plugin>\r\n\r\n <\/plugins>\r\n <\/build>\r\n <\/profile><\/pre>\nmvn clean install -Pdeploy<\/code><\/p>\n<profile>\r\n <id>deploy<\/id>\r\n <activation>\r\n <property>\r\n <name>deploy<\/name>\r\n <\/property>\r\n <\/activation>\r\n <build>\r\n <plugins>\r\n <plugin>\r\n <groupId>net.wasdev.wlp.maven.plugins<\/groupId>\r\n <artifactId>liberty-maven-plugin<\/artifactId>\r\n <executions>\r\n <execution>\r\n <phase>pre-integration-test<\/phase>\r\n <goals>\r\n <goal>deploy<\/goal>\r\n <\/goals>\r\n <configuration>\r\n <appArchive>${project.build.directory}\/${project.artifactId}.war<\/appArchive>\r\n <serverName>${project.artifactId}<\/serverName>\r\n <installDirectory>${openliberty.installDir}\/wlp<\/installDirectory>\r\n <\/configuration>\r\n <\/execution>\r\n <\/executions>\r\n <\/plugin>\r\n <\/plugins>\r\n <\/build>\r\n<\/profile><\/pre>\nmvn clean install -Pstop-liberty<\/code><\/p>\nFatjar distribution<\/h2>\n
mvn clean install -Ppackage-liberty<\/code>:<\/p>\n<profile>\r\n <id>package-liberty<\/id>\r\n <activation>\r\n <property>\r\n <name>package-liberty<\/name>\r\n <\/property>\r\n <\/activation>\r\n <build>\r\n <plugins>\r\n <plugin>\r\n <groupId>net.wasdev.wlp.maven.plugins<\/groupId>\r\n <artifactId>liberty-maven-plugin<\/artifactId>\r\n <executions>\r\n <execution>\r\n <phase>package<\/phase>\r\n <goals>\r\n <goal>package-server<\/goal>\r\n <\/goals>\r\n <configuration>\r\n <packageFile>${project.build.directory}\/${project.artifactId}.jar<\/packageFile>\r\n <include>runnable<\/include>\r\n <serverName>${project.artifactId}<\/serverName>\r\n <installDirectory>${openliberty.installDir}\/wlp<\/installDirectory>\r\n <\/configuration>\r\n <\/execution>\r\n <\/executions>\r\n <\/plugin>\r\n <\/plugins>\r\n <\/build>\r\n\r\n<\/profile><\/pre>\njava -jar quote-service.jar<\/code><\/p>\nprofiles<\/code> you can test the example app with:<\/p>\nmvn -Dtest=com.github.phillipkruger.quoteservice.QuoteApiIT surefire:test<\/code><\/p>\n{\r\n \"author\":\"Naguib Mahfouz\",\r\n \"text\":\"You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions.\"\r\n}<\/pre>\nFine-tuning the memory footprint.<\/h3>\n
javaee-7.0<\/code> and microProfile-1.2<\/code> features, even though my application only uses a subset of these specifications.<\/p>\njconsole<\/code> I measured the memory footprint (after a GC) of the running server:<\/p>\nserver.xml<\/code> to only include the features your app is using, in my example:<\/p>\n<feature>jaxrs-2.0<\/feature>\r\n<feature>ejb-3.2<\/feature>\r\n<feature>cdi-1.2<\/feature>\r\n<feature>jsonp-1.0<\/feature>\r\n<feature>jaxrsClient-2.0<\/feature>\r\n<feature>mpConfig-1.1<\/feature>\r\n<feature>mpFaultTolerance-1.0<\/feature><\/pre>\n
jconsole<\/code> I measured the memory footprint (after a GC) of the running server:<\/p>\npom.xml<\/code> to only include the specification you use.<\/p>\nConclusion<\/h2>\n
More info<\/h2>\n
\n
\n