Simple sample: Dockerized Java app using a maven plugin

It’s good to be able to build Docker images directly from artifacts (JAR, WAR etc.) produced by Maven builds. One useful tool is the Spotify Docker Maven plugin which can help with this

This example (available on Github)

  • uses Jersey Grizzly connector to build a simple REST app
  • packages this as a (Uber) JAR using Maven
  • the maven build process pushes this as a Docker image (thanks to the plugin)

The pom.xml itself incorporates the Docker related configuration which is generally encapsulated in a Dockerfile (this mode is supported by the plugin as well). Here is a snippet..


Hope this gives you a simple yet useful starting point



Posted in Docker, Java | Tagged , , , , , | Leave a comment

Deploying WebSocket annotated & programmatic server endpoints together

One of my previous blog post discussed Programmatic WebSocket endpoints and their deployment methodology using the javax.server.ServerApplicationConfig class.

When annotated and programmatic endpoints co-exist…

you have to make use of the a custom implementation of ServerApplicationConfig and explicitly return set of all annotated endpoints from the getAnnotatedEndpointClasses method

Please note that: using this method, you can choose to restrict the endpoints (annotated and programmatic) being deployed i.e. not all the detected endpoints need to be (will be) deployed

This is how it works..

If the WebSocket container finds subclass of ServerApplicationConfig, it uses the same to deploy both programmatic and annotated endpoints. The result of the WAR scanning process (by the Servlet container) is passed on the methods of this class

  • For getEndpointConfigs, the set (java.util.Set) of detected programmatic endpoints are passed as the method parameter
  • For getAnnotatedEndpointClasses method, the set (java.util.Set) of detected annotated endpoints are passed as the method parameter

Summary of deployment scenarios

Annotated Endpoint Programmatic Endpoint Behavior
Yes No Automatic detection of annotated endpoint. No custom code needed
No Yes Custom implementation of ServerApplicationConfig is compulsory. Programmatic endpoints are not auto-detected and deployed
Yes Yes Custom implementation of ServerApplicationConfig is compulsory. Need to explicitly return set of all annotated endpoints from the `getAnnotatedEndpointClasses` method


Posted in Java EE | Tagged , , , | Leave a comment

Using JCache event listeners + loaders & writers

This blog will

  • zoom through JCache events, loaders and writers
  • look at scenarios when they are used together

You can download the sample maven project from this Github repo. It consists of

  • simple Listener, read through, write through examples
  • along with some test cases to demonstrate the point

Reacting to cache events and external store integration

JCache defines cache event listeners and Cache Loader/Writer features

Event listeners

  • react to cache events – create, update, delete, expiry
  • triggered as a result of many Cache actions (methods on javax.cache.Cache) e.g. get, put, remove etc.


  • Provide transparent way to integrate the cache with external store
  • Ability to implement this in form of Cache Loader (read from external source if key is not present in cache) and Cache Writer (update the external store in case of new entry, update or delete)
  • Caches which implement this are also known as Read Through and/or Write Through

When they are used together …

Let’s look at the sequence of events when everything works in tandem


An example where a key (which did not previously exist) is looked up from the cache



An example where, a new key-value pair is inserted in the cache



Things work similarly in case of updated or removed cache entries

Its worth noting that

  • Event listeners are Synchronous: i.e. they are invoked in same thread as the caller (e.g. the one invoking the get operation on the cache). Thus, that value can’t be returned to caller while event listener is still executing
  • Exceptions during cache entry listener invocation has no impact on the cache itself since it (the cache) has already undergone changes (create/update/delete)
  • One should not invoke cache operations from event listener callbacks, loaders or writers implementations – check spec page 133 (#10)

Additional reading




Posted in Java EE | Leave a comment

CI/CD using Oracle Developer Cloud service

Here is another blog which I published on the Oracle Cloud Developer Solutions portal – Continuous Deployment to App Container Cloud using Developer Cloud service . If you’re interested in exploring how Oracle Cloud solutions can help you seamlessly manage your application (a lightweight fat JAR Java EE app in this case) lifecycle from within your IDE (NetBeans in this case), you should peek into this


Here is a quick overview

  • Leveraging NetBeans IDE while working with Oracle Developer Cloud service. This includes
    • Setting up the Team Server plugin
    • Leveraging it to interact with Developer Cloud service instance from within your IDE
  • Priming Developer Cloud service for Continuous Deployment


Posted in Cloud, Java, Java EE, Oracle Application Container Cloud, Oracle Cloud | Tagged , , | Leave a comment

Simple sample: Oracle NoSQL with Docker Compose

Here is an example of using the Dockerized Oracle NoSQL image. This, along with many other Dockerized Oracle products are available here


Key points

  • Demonstrates usage of Docker Compose : co-ordinates an Oracle NoSQL container and a dependent container running its (Java) client
  • Docker Containers
    • Oracle NoSQL ‘kvlite‘ instance (simple enough for demonstration)
    • A Jersey + Grizzly based Fat JAR application which acts as a client

Jersey App Image

  • Built from latest openjdk image
  • exposes a REST interface to put keys into Oracle NoSQL instance and retrieve the key (return the inserted time stamp)

Oracle NoSQL Image

  • The Docker Hub image is directly referenced in docker-compose configuration
  • Shows this as an example along with the build image pattern demonstrated by the Jersey app

Its very simple to setup – instructions available here. All you need to do is make sure that you have Docker installed🙂


Posted in Docker, Java, Java SE | Tagged , , , , , , | Leave a comment

Java EE microservices with Oracle Application Container Cloud and Wildfly Swarm



Just wanted to drop a note regarding one of the blogs I recently published on the Oracle Cloud Developer Solutions portal – Building ‘right sized’ Java EE applications with Oracle Application Container Cloud and Wildfly Swarm . You should check it out !🙂

Here is an overview …

  • Uses Java EE 7 APIs – JAX-RS, WebSocket, EJB, CDI, JSON-P
  • Covers aspects of developing lightweight Java EE microservices for the Oracle Application Container Cloud
  • Uses Wildfly Swarm to select ‘only the required’ APIs and package them as Uber/Fat JAR
  • It also has a attached ZIP file with the code which you can download and experiment with

Enjoy… Cheers!

Posted in Java, Java EE | Tagged , , , , , , | Leave a comment

My picks for Java EE track @ JavaOne 2016

Its time for JavaOne 2016 with a great line up of Java EE talks… Here are my favorite picks, filed into three categories. You should definitely consider attending few of these if you are one of the lucky JavaOne attendees !🙂

  • Java EE 8 – covers evolution of Java EE 8 in general along with talks targeted at the upcoming specifications (new, updated)
  • Java EE Microservices – these talks focus on how microservices based applications can be built using Java EE specifications
  • General – any other talk focusing on Java EE 7 or specific Java EE APIs

Please note that there are other Java EE talks as well and the ones listed here just happen to be my favorites and reflect my personal opinion only

Java EE 8

  • Java EE 8 Update – what’s been done, shift in focus, JSRs (new and current)
  • Java EE for the Cloud – discussions, feedback with Java EE spec leads
  • What’s Next for Enterprise Java? – A key discussion platform where panelists (including key Java EE architects and leaders from the enterprise community) will weigh in on directions they think enterprise Java should take
  • JAX-RS 2.1 for Java EE 8 – new features like CDI integration, SSE, NIO etc.
  • Java EE Next: HTTP/2 and REST Opportunities – what can Java EE 8 offer in these areas…
  • Security for Java EE 8 and the Cloud – revolves around JSR 375..
  • Servlet 4.0: Status Update and HTTP/2 Comes to Java EE 8 – how can it help in the ‘modern’ cloud era ?
  • JCache and Java EE: Bridging the Gap – technical aspects of  plugging JCache into JavaEE 8
  • What’s New in the Java API for JSON Binding – latest status from JSR 367 and including a deep dive exploration
  • Configuration for Java EE 8 and the Cloud – defining a cloud-ready Java EE based configuration standard

Java EE Microservices

  • Migrate Java EE Applications to Microservices and Oracle Java Cloud
  • Live-Coding No-Ceremony Microservices – hacking on nano services with Adam Bien using Java EE
  • Run Your Java EE Apps with WildFly Swarm in Oracle Application Container Cloud – how Wildfly Swarm can make Java EE 7 apps awesome in Oracle Application Container Cloud
  • Cloud-Native Java EE – 12 factor apps with Java EE …
  • BootEE: Creating Lightweight Services with Java EE – what are your options ?

General (Java EE 7 & others)

  • Java EE, Extendable to Functional – never ever miss a David Blevins session! this one is covers CDI scopes, JCA (Java EE 7) along a discussion of functional programming paradigms apply to Java EE (both 7 and maybe even v8)
  • Java EE Applications on Oracle Java Cloud Service – the title says it all
  • REST in Peace with Java EE : a real world Java EE 7 story about REST API implementation for Dataverse
  • Second-Level Cache in JPA Explained: self evident I guess..
  • Java EE 7 Meets Java 8: learn how to leverage Java 8 for Java EE 7 apps (powered by live coding)
  • Java EE: Beyond the Basics – get hands on with intermediate & advanced Java EE 7 features
  • Top 50 Java EE 7 Best Practices – as per title, fortified with code samples

You might want to check out


Posted in Java EE | Tagged , , , | Leave a comment

JSON-B test drive using JAX-RS

This is a quick post about JSON-B specification which is due in Java EE 8. It’s main purposes are

  • Provide JSON binding i.e. marshalling and un-marshalling to and from Java objects
  • Eclipselink will server as Reference Implementation
  • Supports Java object model to JSON mapping via annotations
  • Supports default mapping for implicit transformations b/w Java model and JSON (without annotation/additional metadata)
  • Produce JSON schema from Java classes
  • Support further customization of default mapping mechanisms as well as partial mapping (part of JSON doc needs to be mapped to Java model)
  • Will integrate with JSON-P and probably with JSON API JEP 198 (Java SE API for JSON processing) if needed

Please note that

  • this is just a quick test of the JSON-B implementation in a Java EE 7 container
  • not an ideal scenario i.e. it does not demonstrate integration of the JSON-B spec with a Java EE container (at least not yet)
  • I am not aware of Java EE 8 builds which ship with JSON-B implementation as of now

From a (Java EE 8) container integration perspective (near future)

the integration should/will be seamless and transparent – the way it is in case of JSON-P and JAXB annotated classes i.e.

  • you will ideally be able to annotate your Java classes using JSON-B annotations and
  • expect them to get serialized/deserialized automatically by the container (e.g. JAX-RS runtime) automatically

Overview of what was done

  • Have a simple POJO
  • Expose POJO using JAX-RS (GET, POST)
  • Use JAX-RS Message Body Reader and Writer – this overrides the default JSON-P providers and leverage JSON-B API here (simply use the default mapping feature) for transformation
  • Repeat the same for a ‘List of’ POJOs

Github project available here – this is not a Maven project. Ideally, you would want to clone into NetBeans, build and run on a Java EE 7 container. Make sure to have RI JAR in WAR (details below)

To be noted

  • I could not grab the Maven artifact of the JSON-B API JAR (maybe I am missing something), so ended up including the JSON-B API sources in the WAR itself
  • Same case with the RI – Downloaded it directly from here

More than this example, what’s important is the following


Posted in Java, Java EE | Tagged , , , , , , | Leave a comment

Nuances of JAX-RS client side async callback

Going async with JAX-RS

JAX-RS provides client side asynchronous behavior to complement its server side counterpart. It’s powered by the AysncInvoker interface – the best part if that you do not need to get hold of it explicitly. The fluent JAX-RS client API makes it available by including the async() call in your builder calls

e.g. ClientBuilder.newClient().target(“”).request().async().get

Like every other asynchronous offering, the JAX-RS client API offers you a couple of options to manage async calls

  • DIY (do-it-yourself) – get back a Future instance and work with it to track the result
  • Declarative callbacks – let the API know what you want it to do in case of a success or failure

Declarative callbacks

A callback is required to implement the InvocationCallback interface. It defines two methods

  • completed: gets called when an invocation successfully finishes. The result response is passed as a parameter to the callback method.
  • failed: it is invoked in case of a failure

Here is an example

There is more to failure scenarios than meets the eye

The invocation of the failed method happens only in case of a failure – no doubts there. But there is a caveat – the criteria is based on the generic entity type (Java class type to be specific) of the response from the server.

Here is an example for the normal scenario

When the response type is anything other than

In case of a server side error (e.g. HTTP 404), the failed method is invoked

What if the generic type if

In such scenario, the completed method is invoked – that’s the catch! You can always investigate the actual HTTP response by calling the getStatus method (as demonstrated in the below example)

At the outset, it might look odd ….

but think about it – you were expecting a response from the service and you did get one (it does not matter if it was success/failure). From the framework’s perspective, only if the API call to the endpoint failed to go through i.e. there was a client side error during invocation, should the failed method should be called. This is an important distinction/caveat which one should make a note of…

Further reading


Posted in Java, Java EE | Tagged , , , | Leave a comment

Java Websocket containers: the possibilities

The Java Websocket API (JSR 356) specification supports different containers

  • Good old Java EE 7 app servers – since Websocket API is integrated directly into the Java EE 7 Platform
  • Servlet 3.1 containers
  • Standalone containers – for runtimes which are not servlet complaint

Hello Tyrus !

Tyrus is the reference implementation for Java Websocket API

  • What’s important to understand is that it’s the implementation of the Websocket specification i.e. it provides both Server and Client side support for building Websocket applications using the standard JSR 356 APIs
  • It’s not an out-of-the-box container i.e. does not have a runtime as such

So, how does Tyrus support the above mentioned runtimes ?

Here is how

  • Tyrus has a modular architecture i.e. it has different modules for server, client implementations, a SPI etc.
  • It has the concepts of containers (you can think of them as connectors) for specific runtime support (these build on the modular setup)

Tyrus containers

Servlet container a.k.a tyrus-container-servlet

  • Used to integrate with existing Servlet 3.1 containers
  • Leveraged to plug into the Web (Servlet) Container in Java EE 7 compliant app servers

Standalone container

You have two options

Grizzly Container (tyrus-container-grizzly module)

  • This is achieved with Grizzly (which provides the runtime)
  • Can be used for server or client (or both) modes as per your requirements

Here are the Maven dependencies

Here is the Websocket (annotated) endpoint

Here is how to start it (embedded)

Pure JDK container (tyrus-container-jdk-client module)

  • Client only mode
  • Vanilla JDK i.e. no additional dependencies
  • Leverages JDK 1.7 non-blocking I/O (Asynchronous Channel)

Maven dependencies

The (annotated) client endpoint

Client code to connect to Websocket endpoint (outlined above)



Posted in Java EE | Tagged , , , , , | Leave a comment