Try out JSON-B 1.0, JPA 2.2 using Java EE 8 on Glassfish 5 & Docker

Glassfish 5 Build 11 is now available – with support for many of the Java EE 8 specifications e.g. JAX-RS 2.1, JPA 2.2, JSON-B 1.0 etc. For more details check out the Aquarium space. This blog covers


It’s a simple one – available on Github

  • Has a REST endpoint (also a @Stateless bean)
  • Interacts with an embedded (Derby) DB using JPA – we use the jdbc/__TimerPool present in Glassfish to make things easier
  • Test data is bootstrapped using standard JPA features in persistence.xml (drop + create DB along with a SQL source)

JSON-B 1.0 in action

Primarily makes use of the JSON-B annotations to customize the behavior

  • @JsonbProperty to modify the name of the JSON attribute i.e. its different as compared to the POJO field/variable name
  • @JsonbPropertyOrder to specify the lexicographical reverse (Z to A) order for JSON attributes

For more, check out Yasson which is the reference implementation

JPA 2.2 in action

The sample application uses the stream result feature added to Query and TypedQuery interfaces by which it’s possible to use JDK 8 Streams API to navigate the result set of a JPA (JPQL, native etc.) query. For other additions in JPA 2.2, please check this

Run on Docker and test…

Check the README


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

CDI (2.0) Async Events

Glassfish 5 builds for Java EE 8 are rolling along… here is another Docker based example on Github. This time it’s asynchronous events in CDI 2.0 (JSR 365)


Just follow the README… just a bunch of docker commands to get started..!

What’s going on

Here is a quick summary

  • A Java EE scheduler triggers asynchronous CDI events (fireAsync())
    • These CDI events are qualified (using a custom Qualifier)
    • It also uses a custom java.util.concurrent.Executor (based on the Java EE Concurrency Utility ManagedExecutorService) – thanks to the NotificationOptions supported by the CDI API
  • Two (async) CDI observers (@ObservesAsync) – a JAX-RS SSE broadcaster and a Websocket endpoint
  • SSE & Websocket endpoints cater to their respective clients – details on how to connect in the README

Notice the asynchronous events running in Managed Executor service thread


You can choose to let things run in the default (container) chosen thread


Further reading




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

Java EE + Debezium

I just published a post – Debezium test drive. It uses Kafka and Java EE… check it out if this interests you


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

Glassfish 5: JAX-RS SSE quickstart

Latest Glassfish 5 build 08 was announced today which includes JAX-RS 2.1 (JSR 370) integration. I am fond of Server Sent Events (SSE), so let’s take it for a test ride – here is a Docker based quick start on Github



Posted in Java, Java EE | Tagged , , , , , | 1 Comment

Validate JAX-RS query parameters


It’s easy to validate parameters in JAX-RS using filters – ContainerRequestFilter to be specific. There are other options at your disposal e.g. using (CDI or EJB) interceptors, or injecting (HttpServletRequest using @Context)

Scenario – Validate query parameter passed in by the caller


  • Implement filter
  • Extracts query parameter from ContainerRequestContext
  • Performs the validation – aborts the request with an appropriate response status (and the error message)

Enforce filter

  • Use @NameBinding to decorate custom annotation
  • Use the custom annotation on the JAX-RS method

Further reading




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

Accessing HTTP Session in WebSocket endpoint

It’s possible to obtain a reference to the HttpSession within a WebSocket application using a custom implementation of ServerEndpointConfig.Configurator

Here is an example application on Github


  • Override the modifyHandshakeRequest method
  • call the getHttpSession method on the HandshakeRequest object which is passed into the method by the WebSocket runtime
  • store it – one possible option is to use the Map provided by the ServerEndpointConfig object (via the method getUserProperties)

This map can then be accessed within the @OnOpen callback (in case of an annotated @ServerEndpoint implementation) using the EndpointConfig object which is passed in automatically by the WebSocket runtime


The WebSocket implementation does not create a Http Session, it just asks for one if it exists. Don’t be surprised if you find a null HttpSession in your configurator method. To have the session created for, you would need to call  getSession  in HttpSession from within a servlet Filter or ServletRequestListener

Check the README for more details

Other things to know…

  • By default, the WebSocket implementation does not handle the life cycle of Http and WebSocket sessions together i.e. it is possible for the HttpSession to end but the WebSocket Session to stay alive.. unless…
  • access to the client initiating the WebSocket connection is protected, the WebSocket implementation makes sure that the associated WebSocket Session is terminated along with the HTTP session

Further reading

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

kafEEne #2: Kafka & Concurrency Utilities

Yet another blog post of the kafEEne series – this time, its Java EE Concurrency Utilities in action along with Kafka. As usual, the code is on Github and you can refer to the README on how to get this up and running using Docker


As mentioned, the application is Docker based

  • It uses Zookeeper, Kafka and TomEE (airhacks) Docker images
  • For ease of development and demo, the entire application can be run as a single unit using Docker Compose


We have the following setup for Kafka

  • One topic with three partitions (configured to be auto-created)
  • Automatic offset commit is disabled, and
  • Links to Zookeeper (container) of course


  • The Consumer is the meat of the application
  • It’s a Runnable whose run method polls Kafka cluster (with a configurable time out – 20 secs by default)
  • It also doubles as a ManagedTask (from the Java EE Concurrency Utilities)
  • Provides implementation for a ManagedTaskListener whose life cycle events are used to commit offsets to Kafka (automatic offset commit is disabled)
  • The Consumer is triggered using a @Singleton bean which schedules it within the ManagedExecutorService thread pool


  • It’s a Runnable
  • Triggered using a @Singleton bean within the ManagedScheduledExecutorService thread pool
  • It waits for a configurable (3 seconds by default) before producing the next record

Checking the results


The results you’ll see might be similar to this. Here is the gist

The above snapshot shows data from three (consumer) poll loops

  • Producer pushed one record
  • Each loop fetched 1 record (that’s just co-incidence, not by design) and its completely independent of the producer
  • After each loop (task), the offset commit process got triggered – in this example we have 3 partitions and the offset for each partition is printed to the console
  • If you notice carefully, the committed offset (for a particular loop) will be in line with the data which was consumed (note: committed offset points to the next offset i.e. one more than the offset that offset which was last consumed)

Further reading


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

Consume from Kafka topics using Message Driven Beans

Thanks to the recently released Payara Kafka Connector, you can now consume messages from Kafka using Message Driven Beans!

Here is a Docker based example for trying it out. Quick overview

Refer to the README for how to run this


Posted in Java EE | Tagged , , , , , , | 2 Comments

kafEEne #1: Websocket & Kafka

Say hello  to kafEEne ! A blog series which will show Kafka and Java EE examples

This one is about Kafka + (Java EE) Websocket API. Code is on Github and you can refer to the README on how to get this up and running using Docker. Although the focus is on Websocket, here is a list of other Java EE specs which have been used – EJB, CDI & a bit of JSON-B (part of Java EE 8)


Websocket based dashboard


  • Kafka Consumer is a @Stateless EJB
  • Initialized in the @PostConstruct callback
  • The consumer logic is executed within a while loop controlled by a (atomic) boolean flag which can potentially be mutated by the container. It sends the event data in form of a custom Payload object using CDI Events
  • Consumer shutdown is exposed within a @PreDestroy method where it invokes the wakeup method to interrupt the consumer while loop
  • A simple (one time) EJB timer job triggers the Consumer process – this is just for simplicity. No harm in exposing the consumer startup through, say, a REST endpoint

See Consumer for more details

Websocket endpoint

A server side Websocket endpoint which is actually does very little to be honest. Client can call it with the interested topic in the URL itself

  • The @OnOpen callback makes sure that the Websocket Session is added and tracked and the topic is added to the Session properties (Map)
  • @OnClose callback removes the Session from the memory


  • It is enabled by a CDI observer (@Observe) for the Payload object
  • Simply loops over all the Sessions and broadcasts the key-value pair (received from the Kafka topic) if it registered for that topic to begin with
  • It uses the JSON-B API to convert the Payload POJO to a JSON format

See KafkaWebsocketEndpoint for more details

Connected clients

  • A @Singleton EJB maintains a list of connected clients
  • Its provides a synchronized wrapper over the collection of Websocket Session objects

See Peers for more details

Websocket Client

A simple Javascript based front end. See index.html for more details. I am not a front end guy – please pardon me!

Producer application

It’s a bare bones Java based producer application which pushes random data to couple of Kafka topics

Further reading


Posted in Java EE | Tagged , , , , , , , | 1 Comment

Redis CDI example….

Here is an example of a CDI producer for Redis using the Jedis (Java) client for Redis. Check out the project README to get this up and running…. Below is a quick summary

Use of CDI Qualifier

Two types of CDI producers have been demonstrated

  1. non-qualified: no additional qualifiers for simply obtaining a standalone Jedis connection
  2. qualified: uses a custom CDI Qualifier (@FromJedisPool) to get the connection from the Jedis pool


  1. @RequestScoped for pooled producer: the Jedis connection is returned to the pool after the method invocation is complete
  2. @DependentScoped for basic producer: the lifetime of the Jedis connection object depends on which component has injected it

Common stuff

  1. In both the cases, the producer (CDI) bean itself is @ApplicationScoped and the producers have been scoped differently
  2. An equivalent @Disposes method has been provided to perform clean up (i.e. close the connection or return it to the pool)

Further reading


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