Using @Context in JAX-RS [ part 1 ]

JAX-RS provides the @Context annotation to inject a variety of resources in your RESTful services. Some of the most commonly injected components are HTTP headers, HTTP URI related information. Here is a complete list (in no specific order)

  • HTTP headers
  • HTTP URI details
  • Security Context
  • Resource Context
  • Request
  • Configuration
  • Application
  • Providers

Lets look at these one by one with the help of examples

HTTP headers

Although HTTP headers can be injected using the @HeaderParam annotation, JAX-RS also provides the facility of injecting an instance of the HttpHeaders interface (as an instance variable or method parameter). This is useful when you want to iterate over all possible headers rather than injecting a specific header value by name

HTTP URI details

UriInfo is another interface whose instance can be injected by JAX-RS (as an instance variable or method parameter). Use this instance to fetch additional details related to the request URI and its parameters (query, path)


An instance of the Providers interface can be injected using @Context. One needs to be aware of the fact that this is only valid within an existing provider. A Providers instance enables the current Provider to search for other registered providers in the current JAX-RS container.

Note: Please do not get confused between Provider and Providers.


  • A JAX-RS Provider is a is generic term for any class which supplements/extends the JAX-RS features by implementing standard interfaces exposed by the JAX-RS specification
  • It is annotated using the @Provider annotation for automatic discovery by the run time
  • Examples of JAX-RS providers are – Message Body Reader, Message Body Writer, Exception Mapper and Context Providers.


Refers to the (injectable) interface which was discussed in this sub section

Security Context

Inject an instance of the interface (as an instance variable or method parameter) if you want to gain more insight into identity of the entity invoking your RESTful service. This interface exposes the following information

  • Instance of representing the caller
  • Whether or not the user if a part of a specific role
  • Which authentication scheme is being used (BASIC/FORM/DIGEST/CERT)
  • Whether or not the request invoked over HTTPS

That’s all for this part. Rest of the injectables will be covered in the next iteration.

Until then.. Cheers!

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

Timeout policies for EJBs : how do they help…?

EJB 3.1 introduced timeout related annotations as a part of its API.

  • @AccessTimeout
  • @StatefulTimeout

Let’s quickly look at what they are and why are they important


Specifies the time period after which a queued request (waiting for another thread to complete) times out.

When your session bean instances are bombarded with concurrent requests, the EJB container ensures sanity by serializing these calls i.e. blocking other threads until the current thread finishes execution. You can refine this behavior further by using this annotation.

Which beans can leverage this annotation ?

This is applicable for

  • Stateful (@Stateful) beans and
  • Singleton beans (@Singleton) configured with container managed concurrency option (ConcurrencyManagementType.CONTAINER)

Why is it important ?

Since the EJB container serializes concurrent requests, having this annotation ensures that the potential (waiting) threads are not kept blocked for ever and helps define a concurrency policy.

Where can I put this annotation?

  • On a class – globally applies to a all the methods
  • On a particular method only
  • On a particular method to override the settings of the class level annotation

How to use it ?

You can use the value and unit elements of this annotation to define its behavior

Here are a few options

  • @AccessTimeout(0) – this means that your method does not support concurrent access at all and the client would end up getting a java.ejb.ConcurrentAccessException
  • @AccessTimeout(-1) – your method will block indefinitely (I don’t think that’s good idea !)
  • @AccessTimeout(5000) – method will wait for 5000 ms (5 seconds) before the next thread in queue (if any) if given a chance

Few things to note

  • Default value for the unit element is java.util.concurrent.TimeUnit.MILLISECONDS
  • a timeout value of less than -1 is invalid


Defines the threshold limit for eviction of idle stateful session beans i.e. the ones which have not received client requests for a specific interval

Why is it important ?

Imagine you have a stateful session bean handling a user registration workflow. The user is inactive for certain time interval (probably doing other stuff). How long would you want your stateful session bean active in the memory ? Configuring this annotation can help prevent inactive bean instances from hogging the main memory.

Where can I put this annotation?

Same rules as the @AccessTimeout annotation !

How to use it ?

You can use the value and unit elements of this annotation to define its behavior

Here are a few options

  • @StatefulTimeout(0) – this means that your bean instance will be removed immediately after the completion of the method which holds this annotation
  • @StatefulTimeout(-1) – your method will not be sensitive to time outs (man that’s stubborn !)
  • @StatefulTimeout(15000) – method will wait for 15000 ms (15 seconds) for client requests before it becomes a candidate for eviction

Few things to note

  • Default value for the unit element is java.util.concurrent.TimeUnit.MILLISECONDS
  • a timeout value of less than -1 is invalid

Cheers !

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

Handling time outs in Async requests in JAX-RS

JAX-RS 2.0 provides support for asynchronous programming paradigm, both on client as well as on the server end. This post which highlights the time out feature while executing asynchronous REST requests on server side using the JAX-RS (2.0) API

Without diving into too many details here is a quick overview. In order to execute a method in asynchronous fashion, you just

  • need to specify an instance of AsyncResponse interface as one of the method parameters
  • annotate it using using the @Suspended annotation (JAX-RS will inject an instance of AsyncResponse for you whenever it detects this annotation)
  • need to invoke the request in a different thread – recommended way to do this in Java EE 7 is to use Managed Service Executor

Behind the scenes ??

The underlying I/O connection b/w the server and the client continues to remain open. But there are scenarios where you would want not want the client to wait for a response forever. In such a case, you can allocate a time out (threshold)

The default behavior in case of a time out is a HTTP 503 response. In case you want to override this behavior, you can implement a TimeoutHandler and register it with your AsyncResponse. In case you are using Java 8, you need not bother with a separate implementation class or even an anonymous inner class – you can just provide a Lambda Expression since the TimeoutHandler is a Functional Interface with a Single Abstract Method


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

Book review: WildFly Configuration, Deployment, and Administration

This is a review of the book WildFly Configuration, Deployment, and Administration. Thanks to Packtpub for providing a review copy !

6232OS_WildFly Configuration, Deployment_Cov

This book has been written by Christopher Ritchie. It covers the breadth and depth of WildFly 8 application server and talks about topics such as

  • Installation and configuration of WildFly, its subsystems, Enterprise services and containers as well as Undertow (web container)
  • Domain configuration, application deployment, high availability and security management
  • OpenShift cloud (PaaS) platform

Let’s look at the book contents in greater detail. The book consists of 11 chapters dealing with various facets of Wildfly.

Chapter 1: Installing Wildfly

This lesson is a gentle introduction to Wildfly. It’s aimed at helping you get up and running with an environment so that you can work on the server. It discusses basic topics and covers

  • Details around installation of Java and Wildfly application server
  • Basic administrative operations such as startup, shutdown and reboot
  • Set up of Eclipse (for Java EE) and JBoss Tools (Eclipse plugin)
  • Wildfly file system (server installation directory) along with kernel and server modules

For me, the highlight of the chapter were the sections around Wildfly Kernel and Modules. It provides a great launching pad for upcoming topics!

Chapter 2: Configuring the Core WildFly Subsystems

This chapter provides an overview of Wildfly configuration which is composed of several sub systems which are configured as a part of the standalone.xml or domain.xml (configuration file)

  • Server subsystems such as Extensions, Profiles, System properties, Deployments etc
  • Thread pool system – discusses configuration revolving around thread factory and thread pools such as bounded queue thread pool, scheduled thread pool, queueless thread pool etc
  • Dwells into the server logging configuration discusses different handlers of the logging subsystem – console, async, size-rotating, custom handlers and more

Chapter 3: Configuring Enterprise Services

This lesson discusses Wildfly subsystems corresponding to Java EE services and their respective configurations

  • JDBC driver and Datasource configuration
  • EJB container configuration including session, stateless, MDB and EJB timers related details
  • Configuring the JMS/Messaging system
  • JTA (transaction manager) configuration
  • Tuning and configuring container resources related to Concurrency utilities API – Managed thread factory, Managed Executor service and managed scheduled executor service

Chapter 4: The Undertow Web server

As the name indicates, this chapter introduces the basic concepts of Undertow (new web container implementation in Wildfly) as well as its configuration related artifacts.

  • Quick tour of the Undertow component architecture
  • Configuration of server listener. host along with servlet container components
  • Walkthrough of creation and deployment of a Maven based Java EE 7 project along with components like JSF, EJB, CDI, JPA

Chapter 5: Configuring a Wildfly Domain

Chapter 5 is all about the concept of a domains in Wildfly and the nuances related to their configuration. It concludes with a section which helps the reader configure a custom domain and apply the concepts introduced in the lesson

  • An overview of domains and related configuration in Wildfly and administrative basics such as start/stop
  • Configuration related to core facets of a domain – host.xml, domain.xml, domain controller etc
  • Tuning domain specific JVM options
  • Configuration of a test (custom) domain

Chapter 6: Application Structure and Deployment

The chapter discusses important topics such as application package structure of different Java EE components and how to deploy various flavors of Java EE applications on Wildfly

  • Review of application packaging options – JAR, EAR, WAR
  • Deployment of applications on Wildfly – standalone and domain mode using both command line and Admin console
  • The chapter ends with a solid section covering Java EE classloading requirements and how Wildfly handles it

Chapter 7: Using the Management Interfaces

Again, as evident in the name of the chapter itself, its not surprising to know that this lesson covers the management options available in Wildfly

  • Usage of the command line interface for execution of various tasks
  • The Wildfly Web Console and the options it offers

Chapters 8,9: Clustering and Load-balancing

Chapters 8,9 cover Wildfly clustering, HA and load balancing capabilities in detail.

  • Basic setup and configuration of a Wildfly clusters
  • Infinispan subsystem configuration along with details of Hibernate cache setup
  • Clustering of JMS system, EJBs and JPA entities
  • Installation and configuration of Apache web server and modules like mod_jk, mod_proxy and mod_cluster
  • Using CLI for mod_cluster and web context management as well as troubleshooting tips

Chapter 10: Securing Wildfly

This chapter covers

  • Introduction to the Wildfly security subsystem and details of commonly used Login Modules – Database and LDAP
  • Securing Java EE components – Web tier, EJBs and web services
  • Protecting the Web Admin console along with configurations related to transport layer security

Chapter 11: WildFly, OpenShift and Cloud Computing

This lesson is dedicated to Cloud Computing as a technology and how OpenShift

  • Overview of Cloud Computing – basics, advantages, types, options
  • Introduction to OpenShift and setup process of the client related tools
  • Walkthrough of cartridge installation and the process of building and deploying a sample application to OpenShift
  • Log management and basic administrative tasks using CLI tools- start, stop, restart etc
  • Using OpenShift with Eclipse and instructions on how to scale your applications

Standout features

Some of the points which in my opinion were great

  • We often spend years working with containers (application servers, web servers etc) without really knowing what’s going on beneath. There is a reason behind this – the core concepts (application kernels, modules, container configuration, threading setup etc) are pretty complex and often not that well explained. This book does a great job at covering these topics and presenting the core of Wildfly in a simple manner
  • Intuitive and clear diagrams (lots of them!)
  • Enjoyed the chapter on OpenShift – provides a great platform for exploring PaaS capabilities and getting up and running with OpenShift


This book is a must have for someone looking to gain expertise on WildFly 8. Since WildFly 8 is Java EE 7 compliant, it also means that the reader will benefit a lot by picking up a lot of Java EE related fundamentals as well as cutting edge features of Java EE 7. Grab your copy from Packtpub !

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

Approval specific web services in Oracle IDM

This is quick post with regards to the web service endpoints which are leveraged by OIM and SOA in the context of an approval related scenario – basic stuff, but can be useful for beginners.

Oracle IDM integrates with and leverages the SOA suite for approval related features (SOA is quite rich to be honest and is utilized as the back bone for Web Services connector as well). SOA is not just for namesake – SOA suite does in fact rely on the concept of loosely coupled and independent services.

The approval engine makes use of three such web services

  • Request web service: this is deployed on the OIM server
  • Request Callback web service: this is deployed on SOA server
  • Provisioning Callback web service: this too is deployed on OIM and used in context of approvals related to Disconnected application instances

But how/when are these (SOA) services leveraged ?

Consider an example of a basic approval process

  • OIM approval engine calls a SOA composite (from within an approval policy) in response to evaluation of a self service request. The internals of this call are out of scope of this post (maybe some other time!)
  • Operations within the SOA composite are executed and here is where the Request Callback web service comes in to play. The SOA composite calls the Request Callback web service and appraises it of the result of the SOA composite execution (approval/rejection)
  • The Request Callback web service calls relays the result back to approval/request engine within OIM which then proceeds accordingly
Request Callback Web Service

Request Callback Web Service

So what is the Request web service all about ?

This is a generic purpose web service available OOTB in OIM (all you need to do is deploy it). It exposes information within OIM such as users, catalog, organizations etc. You can leverage it within SOA composite (just a few click!) to make your life easier (its not mandatory, but you might need to use this more often than not in order to make dynamic decision making)

Provisioning Callback web service

This is used by the OOTB SOA composite (for disconnected applications) to relay the approval decision back to OIM provisioning engine so that it can mark the task as completed and hence the disconnected instance would show up as Provisioned (this of course is the OOTB behavior which is subject to customization if needed)

Provisioning Callback Web Service

Provisioning Callback Web Service

Note: the snapshots presented above are nothing but the BPEL composites as seen in JDeveloper

Until next time…
Cheers !

Posted in Oracle Identity Governance, Oracle Identity Manager | Tagged , , , , , | Leave a comment

Quick peek at JAX-RS request to method matching

In this post, let’s look at the HTTP request to resource method matching in JAX-RS. It is one of the most fundamental features of JAX-RS. Generally, the developers using the JAX-RS API are not exposed to (or do not really need to know) the nitty gritty of the matching process, rest assured that the JAX-RS runtime churns out its algorithms quietly in the background as our RESTful clients keep those HTTP requests coming!

Just in case the term request to resource method matching is new to you – it’s nothing but the process via which the JAX-RS provider dispatches a HTTP request to a particular method of your one of your resource classes (decorated with @Path). Hats off to the JAX-RS spec doc for explaining this in great detail (we’ll just cover the tip of the iceberg in this post though!)

Primary criteria

What are the factors taken into consideration during the request matching process ?

  • HTTP request URI
  • HTTP request method (GET, PUT, POST, DELETE etc)
  • Media type of the HTTP request
  • Media type of requested response

High level steps

A rough diagram should help. Before we look at that, here is the example scenario

  • Two resource classes –,
  • Resource methods paths in – /books/, /books/{id} (URI path parameter), /books?{isbn} (URI query parameter)
  • HTTP request URI – /books?isbn=xyz

Who will win ?


JAX-RS request to method matching process


Break down of what’s going on

  • Narrow down the possible matching candidates to a set of resource classes

This is done by matching the HTTP request URI with the value of the @Path annotation on the resource classes

  • From the set of resource classes in previous step, find a set of methods which are possible matching candidates (algorithm is applied to the filtered set of resource classes)
  • Boil down to the exact method which can server the HTTP request

The HTTP request verb is compared against the HTTP method specific annotations (@GET, @POST etc), the request media type specified by the Content-Type header is compared against the media type specified in the @Consumes annotation and the response media type specified by the Accept header is compared against the media type specified in the @Produces annotation

I would highly recommend looking at the Jersey server side logic for implementation classes in the org.glassfish.jersey.server.internal.routing package to get a deeper understanding. Some of the classes/implementation which you can look at are

Time to dig in….?

Happy hacking !

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

Simplifying JAX-RS caching with CDI

This post explains (via a simple example) how you can use CDI Producers to make it a little easier to leverage cache control semantics in your RESTful services

The Cache-Control header was added in HTTP 1.1 as a much needed improvement over the Expires header available in HTTP 1.0. RESTful web services can make use of this header in order to scale their applications and make them more efficient e.g. if you can cache a response of a previous request, then you obviously need not make the same request to the server again if you are certain of the fact that your cached data is not stale!

How does JAX-RS help ?

JAX-RS has had support for the Cache-Control header since its initial (1.0) version. The CacheControl class represents the real world Cache-Control HTTP header and provides the ability to configure the header via simple setter methods. More on the CacheControl class in the JAX-RS 2.0 javadocs



So how to I use the CacheControl class?

Just return a Response object around which you can wrap an instance of the CacheControl class.

Although this is relatively convenient for a single method, repeatedly creating and returning CacheControl objects can get irritating for multiple methods

CDI Producers to the rescue!

CDI Producers can help inject instances of classes which are not technically beans (as per the strict definition) or for classes over which you do not have control as far as decorating them with scopes and qualifiers are concerned.

The idea is to

  • Have a custom annotation (@CacheControlConfig) to define default values for Cache-Control header and allow for flexibility in case you want to override it

  • Just use a CDI Producer to create an instance of the CacheControl class by using the InjectionPoint object (injected with pleasure by CDI !) depending upon the annotation parameters

  • Just inject the CacheControl instance in your REST resource class and use it in your methods

Additional thoughts

  • In this case, the scope of the produced CacheControl instance is @Dependent i.e. it will live and die with the class which has injected it. In this case, the JAX-RS resource itself is RequestScoped (by default) since the JAX-RS container creates a new instance for each client request, hence a new instance of the injected CacheControl instance will be created along with each HTTP request
  • You can also introduce CDI qualifiers to further narrow the scopes and account for corner cases
  • You might think that the same can be achieved using a JAX-RS filter. That is correct. But you would need to set the Cache-Control header manually (within a mutable MultivaluedMap) and the logic will not be flexible enough to account for different Cache-Control configurations for different scenarios

Results of the experiment

Use NetBeans IDE to play with this example (recommended)


  • A GET Request to the same URL will not result in an invocation of your server side REST service. The browser will return the cached value.


Although the code is simple, if you are feeling lazy, you can grab the (maven) project from here and play around

Have fun!

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

Valid CDI scopes for Session (EJB) beans

CDI enriches the EJB specification (Session beans to be specific) by providing contextual life cycle management. Session beans are not ‘contextual’ instances in general.

If you are comfortable with CDI in general, the idea of ‘being contextual’ should be pretty clear.

Here are the valid permutations and combinations of EJB session beans and corresponding CDI scopes (Application, Session or Request)

  • Stateless beans can only belong to the @Dependent scope i.e. you can either choose to use the @Dependent pseudo-scope explicitly or just flow with the @Stateless annotation in which case the CDI container will pretty much use @Dependent by default (convention).

The CDI container will not let you get away with any other annotation and the end result would be a deployment failure

  • With Singleton beans, @ApplicationScoped is the only valid CDI scope (@Dependent is the default in case you do not use any other explicit CDI scope)

Again, any other scope annotation and the CDI god will crush your WAR/EAR !

  • Stateful EJBs can have any scope – no restrictions whatsoever! (although I do not see too much value in using @ApplicationScoped for Stateful beans – but that’s just me! feel free to chime in case you think otherwise)

Stay safe !
Cheers ;-)

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

14 February is drawing closer… again !!!

Once in a blue moon, I choose to post non-technical ramblings on this blog

14 February is dawning upon us… yet again! And this time, I (like many of you guys) am spoilt for choices. It’s Friday after all! So lighten up and help me figure this one out ;-)

Posted in Uncategorized | Tagged , , | Leave a comment

Integrating CDI and WebSockets

Thought of experimenting with a simple Java EE 7 prototype application involving JAX-RS (REST), WebSockets and CDI.

Note: Don’t want this to be a spoiler – but this post mainly talks about an issue which I faced while trying to use web sockets and REST using CDI as a ‘glue’ (in a Java EE app). The integration did not materialize, but a few lessons learnt nonetheless :-)

The idea was to use a REST end point as a ‘feed’ for a web socket end point which would in turn ‘push’ data to all connected clients

  • JAX-RS end point which receives data (possibly in real time) from other sources as an input to the web socket end point
  • Use CDI Events as the glue b/w JAX-RS and WebSocket end points and ‘fire’ the payload

  • Use a CDI Observer method in the WebSocket endpoint implementation to push data to connected clients

Of course, finer details like performance, async communication etc have not being considered at this point of time. More of an experiment

But is this even possible ?

Here are the steps which I executed


  • Fired a HTTP POST request on the REST end point using Postman



Boom! A NullPointerException in the Observer method – I waited for a few seconds and then reality hit me!



Root cause (from what I understand)

  • Behavior of WebSocket end points

WebSocket end points are similar to JAX-RS resource classes in the sense that there is one instance of a web socket endpoint class per connected client (at least by default). This is clearly mentioned in the WebSocket specification. As soon as a client (peer) connects, a unique instance is created and one can safely cache the web socket Session object (representation of the peer) as an instance variable. IMO, this a simple and clean programming model


  • But the CDI container had other plans !

As soon as the REST end point fires a CDI event (in response to a POST request), the CDI container creates a different instance of the WebSocket endpoint (the CDI Observer in this case). Why? Because CDI beans are contextual in nature. The application does not control the instances of CDI beans. It just uses them (via @Inject). Its up to the container to create and destroy bean instances and ensure that an appropriate instance is available to beans executing in the same context. How does the container figure out the context though ? It’s via Scopes – Application, Session, Request etc…..

(again, clearly mentioned in the CDI specification)


So, the gist of the matter is that there is NO instance of the WebSocket endpoint current context – hence a new instance is created by CDI in order to deliver the message. This of course means that the instance variable would point to null and hence the NPE (Duh !)

So the question is . . .

Which CDI scope is to be used for a WebSocket end point ??? I tried @ApplicationScoped, @SessionScoped and @RequestScoped without much luck – still a new instance and a NPE

Any other options ??

  • Defining a Set of Session as static variable will do the trick

But that IMO is a just a hack and not feasible in case one needs to handle client specific state (which can only be handled as instance variables) in the observer method – it’s bound to remain uninitialized

  • Server Sent events ? But at the end of the day, SSE != WebSocket. In case the use case demands server side push ‘only’, one can opt for it. SSE is not a Java EE standard yet – Java EE 8 might make this possible

Solution ?

I am not an expert – but I guess it’s up to the WebSocket spec to provide more clarity on how to leverage it with CDI. Given that CDI is an indispensable part of the Java EE spec, it’s extremely important that it integrates seamlessly with other specifications – specially HTML5-centric specs such as JAX-RS, WebSocket etc

This post by Bruno Borges links to similar issues related to JMS, CDI and WebSocket and how they integrate with each other.

Did I miss something obvious? Do you have any inputs/solutions? Please feel free to chime in ! :-)

The sample code is available on GitHub (in case you want to take a look). I tried this on GlassFish 4.1 and Wildfly 8.2.0

That’s all for now I guess…. :-)


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