This post describes how to develop a Java EE REST service, usually part of a REST API backend, that will provide information about the current version of the implementation plus the git sha-1 number¹. This can be very useful in continuous delivery² scenarios or for the operations team, where they make a smoke test after deployment to “humanly see” if the API is “alive”, plus one gets which version/commit is currently deployed. The post implies you are also using Maven³ to build your project

So when making a GET REST call against the service:

GET http://localhost:8080/some-root-context/version

I would expect something like the following

{
   "version": "1.2.0",
   "gitSha1": "8f0b7f7e1fc0d"
}

where the version attribute displays the version of the project from the pom.xml⁴ file and the gitSha1 attribute contains the first, let’s say 13 characters of the SHA-1 calculated from the git commit that corresponds to this deployment.

Generally, eight to ten characters are more than enough to be unique within a project, but I choose thirteen just to be sure :)

You can then use the gitSha1 value with the git show command to show the corresponding commit:

$ git show 8f0b7f7
commit 8f0b7f7e1fc0dcde3ccc0a9418f37a698dabb3b7
Merge: df736ab 3ebcbdb
Author: Adrian Matei <ama@codepedia.org>
Date:   Sat Dec 3 09:30:41 2016 +0100

    Merge branch 'master' of https://github.com/CodepediaOrg/codepediaorg.github.io

The dev-bookmarks are persisted in a MongoDB Server. Very often I find myself in the situation, where I need to modify or look for something in the mongo database. Experience has taught me that interacting with a system via shell commands helps me understand it better, and sort of brings me closer to it. Ok, so how to find the right mongo shell command? Well, I google for it of course, and most likely I am pointed to the right entry in the Mongo manual. In this post I try to consolidate the commands I usually use, so that I have only one codingmark to look for…

Source code for bookmarks.dev is available on Github - frontend and backend.

In this post I will shortly present how to enable the provided RESTEasy CORS Filter in a REST API backend application. Well, it is officially documented, but for me was not that straightforward to use it and I want to share how I accomplished this. If you are new to CORS and want to learn more about it I suggest you read the document from Mozilla Developer Network - HTTP access control (CORS).

In this post I will briefly describe the steps and issues encountered when migrating a Java EE REST API from JBoss EAP 6 to JBoss EAP 7 - this implies migrating from a Java EE 6/JAX RS 1.0 implementation to a Java EE 7/JAX RS.2.0 implementation. The trigger was the announcement from Red Hat regarding the general availability of their JBoss Enterprise Application Platform 7 (JBoss EAP) ¹. JBoss EAP 7 is based on Wildfly 10², so the code snippets showed along the post should work on Wildfly 10 too.

One of my main concern when I considered the migration from Wordpress to Jekyll was how would I be able to handle multiple authors, because this plays an important role in the website supporting our Coding Friend Program. Fear no more, I have found a satisfactory way to handle multiple authors with Jekyll¹ and in this short post I list the main points concerning that.