Java, Spring, Spring Boot

Logger Injection with Spring’s InjectionPoint

You should all be familiar with the boiler plate code you include on top of your classes to get a Logger instance for use in your classes at runtime.

This is the classic way of obtaining a logger instance at runtime with the classname that you want to be displayed in your log messages like below.

The fully qualified class name org.orwashere.WorkOrderController is retrieved and logged from the class parameter you pass to LoggerFactories getLogger class.

With Spring Framework’s new InjectionPoint feature you can get rid of these boiler plate code in your classes. All you need to do is declaring a prototype scoped Logger bean in one of your configuration classes like below. And from that point you have access to the class’s properties that the Logger bean is being injected to. As we should be creating a new Logger instance for each Spring Bean that we want to enable logging it is important define the Logger bean as prototype scoped.

In your class target bean in which the logger will actually be used all you need to do is injecting the Logger bean as a classic Spring Bean and voila your logger is configured and ready to be used in your class like below.

Even though we are talking about Logger injection in this post, with InjectionPoint support many other opportunities arise before injecting any bean into your class. Basically you can make any kind of configuration on your injected bean depending on the target bean.

Hope it helps you in your feature development!

Happy coding!

Advertisements
Java, RabbitMQ, Spring, Spring Boot

Spring Boot RabbitMQ Dead Letter Queue Configuration

This is going to be a short blog post about how to configure your Spring Boot application with a dead letter queue support for RabbitMQ.

To start let’s summarize the problem description we are trying to solve. You have a Spring Boot application which consumes messages from a RabbitMQ queue and you want the messages to be forwarded to another Rabbit queue in case a problem occurs during message processing.

Although you can implement your application to send the failed messages to a different queue manually this is not always the most effective way of handling the situation.

RabbitMQ supports dead letter exchanges and queues which are first class candidates for solving the problem we have in hand.

For a queue to be able to  handle dead lettered messages it should be defined with dead letter support during creation.

In a Spring Boot application with all required dependencies added it’s simple the enable this feature.

Below spring configuration code snippet creates an exchange, defines two queues and binds both queues to the created exchange. Notice the two arguments being defined during the creation of the spring bean named queue. x-dead-letter-exchange argument is used to define the Rabbit exchange dead lettered messages will be routed to. On the other hand x-dead-letter-routing-key tags the routed messages with the routing key so they can routed to desired queue at the end.

Binding beans at the end completes the configuration by binding the queues to the exchanges with desired routing keys.

Assuming you have RabbitMQ installed and running below configuration will create the exchange, queues and bindings on your rabbit instance.

The last part that requires explanation is how to tell RabbitMQ a message should be dead lettered on your application. RabbitMQ documentation explains the events a message will be dead lettered as follows:

  • The message is rejected (basic.reject or basic.nack) with requeue=false,
  • The TTL for the message expires; or
  • The queue length limit is exceeded.

Last two items is currently out of scope as the messages on those cases are managed by RabbitMQ itself. The first condition is the one that is relevant with our case. So the message should be rejected with basic.reject or basic.nack and requeue parameter should be set to false. Spring Rabbit hides the details gracefully and provides us a  new exception class named AmqpRejectAndDontRequeueException. All you have to do on your application code is to throw this exception and Spring will handle the rest and your message will be requed. Below is a sample code snippet showing the exception in use.

This concludes the blog post. Happy coding!

AWS, Cloud, ElasticBeanstalk, Java, Spring, Spring Cloud

Spring Boot, Spring Cloud AWS and ElasticBeanstalk – Part 2 – Deployment

This is the second part of a two part blog series which was intended for demonstrating development of a web application which is eligible for deployment to AWS platform and utilizes some of AWS provided services like the RDS service.

If you missed the first part which was talking about development of a trivial application using Spring Boot and Spring Cloud AWS you can find it here. This part is going to be talking about AWS ElasticBeanstalk  and how we can utilize it to deploy our application to AWS platform. As our application is backed by a MySQL database and we aim to use RDS service for a relational database I’ll also describe creation of a simple DB instance on RDS. So if everybody is ready let’s start!

Continue reading

AWS, Cloud, ElasticBeanstalk, Java, Spring, Spring Cloud

Spring Boot, Spring Cloud AWS and ElasticBeanstalk – Part 1 – The Application

Recently I was playing around with Amazon Web Services on developing and deploying a java web application which utilizes some of the services provided by AWS like RDS and EC2. What I noticed during my efforts is, there is not much online resources which will help you to quickly ramp up and get ready for deployment. This pushed me to prepare this blog post which will briefly describe the process as a ‘how to’ guide.

The Application

As this is a trivial application and the intention is to only see how easy it’s to prepare and deploy an application on AWS platform there is not much logic involved with it. I decided to develop a Restful back-end application without a web UI which serves a basic restful service consisting of classic GET, POST etc. methods. A MySQL instance backed by AWS RDS is used as the persistence store to see how well it plays with AWS services.

Continue reading