Handling custom objects with JAX-RS SSE API

Information sent using the JAX-RS 2.1 SSE support (in Java EE 8) does not only have to be of String type – it supports Java primitives (Integer , Long etc.), JSON-B & JAX-B annotated types as well as custom objects whose encoding process (Java object to on-wire format) is defined using a MessageBodyWriter implementation

Here is simple example you can try out – no need to setup anything except Docker !

Meanwhile – here is the code snippet

To summarize

  • Multiple ​​OutboundSseEvents have been created – each differing in the data/media type (text, json, xml etc.)
  • the default SSE media type is TEXT_PLAIN, hence does not need to be explicitly specified when dealing with String data type
  • ​​​​​Employee class is a JSON-B annotated class
  • Customer is a JAX-B annotated class
  • Student has a custom MesaageBodyWriter implementation

For more details, just refer to the project

Further reading

Cheers!

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

CompletionStage support in server-side JAX-RS

JAX-RS 2.1 (part of Java EE 8) now supports returning a CompletionStage to mark the request as eligible for asynchronous processing. This is in addition to the AsyncResponse API which has been available since JAX-RS 2.0 (Java EE 7)

Even the Client API has added support for reactive-style programming by providing support for CompletionStage API, but this blog will focus on the server-side support

The advantage this approach has over the AsyncResponse based API is that it is richer and allows you to create asynchronous pipelines. Let’s look at an example – available on Github. It is simple and slightly contrived, but hopefully it should help get the point across 🙂

  • It starts with a HTTP GET to /booking/cabs/<user> which invokes the getCab method
    • the method returns a CompletionStage and returns immediately
    • the thread which served the request is now freed up
  • and then its about creating the asynchronous pipeline
    • we orchestrate the tasks for user validation and driver search using thenComposeAsync – this gives a CompletableFuture i.e. the searchDriverTask
    • we then supply a Function which takes the driver (returned by the above step) and invokes the notifyUser method – this is the CompletionStage which we actually return i.e. notifyUserTask – this is obviously executed later on, all we did was compose the sequence
  • once the process is completed (delays are introduced using Thread.sleep() ), the response is sent back to the user – internally, our CompletableFuture completes

To run using Docker

Refer README

Further reading

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

JAX-RS 2.1 SSE Client API example using Glassfish 5 on Docker

Along with the Server API for SSE, JAX-RS 2.1 (part of Java EE 8) also has an equivalent client side API

Here is a quick peek – you can grab the project from Github

To summarize

  • we use a @Singleton EJB with @Startup
  • during initialization
    • create a single action (one time) Timer  i.e. @PostConstruct
    • and instantiate the SSEEventSource – its a public SSE source
  • when the timer expires, the @Timeout annotated method gets triggered
    • opens the SSE connection
    • prints them out – this action is registered as a callback (written as a Java 8 lamda in this case)
  • Execution thread pool(s) – notice this in the logs
    • the timer itself is triggered in the EJB thread pool
    • SSE event callbacks are executed in the ManagedExecutorService thread pool (thanks to Java EE Concurrency Utilities)

sse-client-output.jpg

To run using Docker

Refer README

Further reading

Cheers!

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

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

Application

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

Cheers!

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)

Steps

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

action-2.jpg

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

cdi-2-async-events-in-action.jpg

Further reading

Cheers!

 

 

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

Cheers!

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

Moar!!!

Cheers!

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

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

Steps

  • 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

Cheers!

 

 

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

Steps…

  • 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

Caveat

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

Setup

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

Kafka

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

Consumer

  • 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

Producer

  • 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

kafka-javaee-conc-utils-snapshot.jpg

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

Cheers!

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