Explore topic-wise InterviewSolutions in .

Popular logging frameworks such as Log4j, Logback, and SLF4J, etc. provide logging functionality for the individual microservice application. However, when a group of run together to provide complete business functionality, it becomes really challenging to TRACE a request across all the services, especially in case of failures.

Hence it is highly recommended to have a centralized logging solution in place, to have all the log messages stored in a central location rather than on local machine/container of each microservice. This eliminates dependency on the local disk space (volumes) and can HELP retain the logs for a long time for analysis in the future.

The Elasticsearch, Logstash, and Kibana tools, collectively known as the ELK stack, provide an end-to-end logging solution in the distributed application; providing a centralized logging solution. ELK stack is one of the most commonly used architectures for custom logging management in cloud-based Microservices applications.

Elasticsearch is a NoSQL database used to store the logs as documents. Logstash is a log pipeline tool that accepts logs as input from various micro service applications, executes transformations if required and stores data into the target (Elasticsearch database).

Kibana is a UI that works on top of Elasticsearch, providing a VISUAL representation of the logs and ability to search them as required.  All three tools are typically installed on a single server, known as the ELK server.

In a centralized logging approach, applications should follow a standard for log messages. Each log message having a context, message, and correlation ID. The context information is ideally can be the IP address, user information, process details, timestamp, etc. The message is a simple text description of the SCENARIO. The correlation ID is dynamically generated and is common across all that used for end-to-end TRACKING of a request/task.

CLOUD Foundry is an open source cloud PaaS (platform as a service) where developers and organizations can build, deploy, run and scale their applications. It is the same company that manages Spring, hence has great support for running Spring based cloud applications.

For deploying an application in Cloud Foundry, we need to configure the application with a target and a space to deploy the application to.

It is increasingly GAINING popularity as an open source and lets US use our own tools and code. Organizations can deploy Cloud Foundry PaaS on their own internal infrastructure; on cloud PROVIDERS' infrastructure, such as Amazon Web Services (AWS) or Microsoft Azure.

It also provides a few out of the box components:

1. Authentication: Contains an OAuth2 server and login server for user identity management.
2. Application Lifecycle: Provides application deployment and management services.
3. Application Storage and Execution: It can control when an application starts and stops, as well as the VM's containers.
4. Service Brokers: Helps connecting applications to services like databases.
5. Messaging: Enables VMS to communicate via HTTP or HTTPS protocols, can also store data like application status.
6. Metrics and Logging. It provides Loggregator tool, which helps organizations monitor their Cloud Foundry environment.

It is very easy to set up and application on Cloud Foundry:

1. Create a pivotal Cloud Foundry account.
2. Create an organization and space to deploy the application.
3. Add the plugin with the configuration of Cloud Foundry org and space in application pom.xml/build.gradle.

Traditional monolithic applications developed in the last few decades had the luxury of CONSIDERABLE response time, multiple hours of offline maintenance and smaller volumes of data. However, this is not acceptable with the modern applications serving high volumes round the clock with an expectation of sub-second response time with 100% availability.

Reactive programming is ONE of the solutions for the above constraints, which is rapidly gaining popularity in cloud-based applications. It is a programming pattern that RECOMMENDS an asynchronous, non-blocking, event-driven approach for data processing. In the reactive style of programming, after making a request for the resource, the application continues to perform other tasks instead of WAITING for the response. When the data is available, the application should get the notification along with data in the form of call back function which handles the response as per business needs.

Systems built as Reactive Systems are highly flexible, loosely coupled, and scalable. This makes them easier to develop and responsive to change. They are significantly more resilient and are able to handle failures gracefully. They are quite responsive and ideal for interactive applications.

Spring Web Reactive brings reactive capabilities for web applications, which is based on the same fundamental programming model as Spring MVC. The base API is 'Reactive HTTP' as opposed to 'Servlet API' and runs only on Servlet Containers like Netty or Undertow.

We need to add 'spring-boot-starter-webflux' to ENABLE Spring Reactive and 'spring-boot-starter-reactor-netty' as the default embedded reactive server; in the application dependencies.

Creating a Spring Reactive Controller is similar to a typical Spring MVC Controller using @RestController and the required @RequestMapping annotations.

In a typical Microservice architecture multiple services collaborate to provide an overall functionality. These set of service instances may have dynamically assigned network locations. Also, the services scale up and down as per the load. It could get tricky in a cloud environment resolving the services that are required for operation for common functionality.

Consequently, in order for a client to make a request to a service, it must use a service-discovery mechanism. It is the process where services register with a CENTRAL registry and other services query this registry for resolving dependencies.

A service registry is a highly available and up to date database containing the network locations of service instances. The two main service-discovery components are client-side discovery and service-side discovery.

Netflix Eureka is one of the POPULAR Service Discovery Server and Client tools. Spring Cloud SUPPORTS several ANNOTATIONS for enabling service discovery.  @EnableDiscoveryClient annotation allows the applications to query Discovery server to find required services.

In Kubernetes environments, service discovery is built-in, and it performs service INSTANCE registration and deregistration.

Netflix’s Hystrix is a library that provides an implementation of the Circuit BREAKER pattern for Microservices based applications. A circuit breaker is a pattern that monitors for failures and once the failures reach a certain threshold, the circuit breaker TRIPS, and all further calls will return with an error, without the external call being made at all.

On applying Hystrix circuit breaker to a method, it watches for failing calls to that method, and if failures build up to a threshold; Hystrix opens the circuit so that subsequent calls automatically fail.

While the circuit is open, Hystrix redirects call to a specified method called a fallback method. This creates a time buffer for the related service to recover from its failing state.

Below are the annotations used to enable Hystrix in a Spring Boot application:

@EnableCircuitBreaker: It is added to the main Application class for enabling Hystrix as a circuit breaker and to enable hystrix-javanica; which is a wrapper around native Hystrix required for using the annotations.

@HystrixCommand: This is method annotation that notifies Spring to wrap a particular method in a proxy connected to a circuit breaker so that Hystrix can monitor it. We also need to define a fallback method having the backup logic that needs to be EXECUTED in the failure scenario. Hystrix passes the control to this fallback method when the circuit is broken.

This annotation can also be used for asynchronous requests. Currently, it works only with classes marked with @COMPONENT or @Service.

Spring Cloud Contract implements the Consumer Driven Contracts (CDC) approach via the 'Spring Cloud Contract VERIFIER' project.

Consumer Driven Contracts is a software DEVELOPMENT and evolution approach where each consumer of SERVICE develops a contract that contains the consumer's expectations about the APIs provided by Service. The full collection of all of the consumers' contracts constitutes the requirement SET for the service.

Once the service owners have all of the contracts for their consumers, the service owners can develop a test suite that VERIFIES the service APIs. This test suite provides rapid feedback about failures when the service changes.

In Spring Cloud Contract, a "producer" is the owner of an API and a "consumer" is the user of an API.

Service A (as a consumer) creates a contract that service B (as a producer) will have to abide by. This contract acts as the invisible glue between services - even though they live in separate code bases and run on different JVMs. Breaking changes can be detected immediately during build time.

Microservices (MS) is an architecture pattern that prescribes to divide an application based on business functionality instead of technical boundaries.  These set of smaller interconnected services constitute the complete application. As opposed to monolithic architecture, it recommends breaking the application into smaller atomic units, each performing a single function.

Typically, an application provides a set of distinct features or functionality, such as order management, billing, customer service, ETC. Each microservice WORKS as a mini-application that has its own hexagonal architecture. It is often compared to Honeycombs (nests) that are a combination of MULTIPLE hexagonal structures.

Below are some of the key features of Microservices that distinguish from monolithic:

1. Tight Cohesion: Single responsibility per service i.e. code perform a single and well-defined task only.
2. Loose Coupling: Microservices are the autonomous i.e. effect of changes are isolated to that particular MS only.
3. Interoperability: One of the key foci of microservices is on communication between systems using diverse technologies.
4. Stateless: An ideal microservice does not have a state i.e. it does not store any information between requests. All the information needed to CREATE a response is present in the request.
5. Devops: It is highly recommended to implement an automated build and release process using suitable CI-CD infrastructure.
6. Developing Products instead of PROJECTS.

@Autowired ANNOTATION is used to AUTOWIRE i.e. inject dependent bean on the constructor, setter method or a field/property. When @Autowired is used on dependency, the application context searches for a matching dependency and provides as required. This helps us to avoid writing EXPLICIT injection logic.

However, by default, all dependencies that are Autowired are required. So, in scenarios where a required dependency is not available or if there is conflict; it results in an exception like NoUniqueBeanDefinitionException.

There are a few options available to turn off the default behavior:

1. By using (required=false) OPTION with @Autowired to MAKE it non-mandatory for a specific bean property.

@Autowired (required=false)

private Contract contractBean;

1. By using @Qualifier, we can further qualify autowiring; in scenarios when two beans are created with the same name.

@Qualifier ("design")

private Contract contractBean;

Traditional Spring controllers are created by ADDING a class with @Controller annotation. It is actually a specialization of the @Component annotation that allows the implementation classes to be autodetected by Spring context through the CLASSPATH scanning.

Generally, @Controller annotation is used in combination with @RequestMapping and @ResponseBody added to the request handling methods to define the REST APIS.

@RestController is a convenient annotation that combines both the features of @Controller and @ResponseBody annotations.

The KEY difference between typical Spring @Controller and the RESTful web service @RestController is the way the HTTP response body is created. While the traditional MVC controller relies on the View technology, the RESTful web service controller returns the object and the object data is written directly to the HTTP response as JSON.

HATEOAS (Hypermedia as the Engine of Application State) is a principle for REST APIs, according to which the API should guide the client through the application by returning relevant information about potential subsequent steps, ALONG with the response.

This information is in the form of hypermedia links included with responses, which helps the client to navigate the site's REST interfaces. It essentially tells the clients what they can do next, and what is the URI of the resource. If a service consumer can use the links from the response to perform transactions, then it would not need to hardcode all links.

According to the Richardson Maturity Model, HATEOAS is considered the final level of REST.

To support HATEOAS, each resource in the application should contain a "links" property which defines hyperlinks to related resources. 

Each link object TYPICALLY includes the following properties:

"rel”: Relation with the TARGET resource.

"href”: URI for resource

For EXAMPLE:

REST stands for REpresentational State Transfer. It is a web standards-based architecture using HTTP Protocol for data communication. A REST Server provides access to resources and REST client accesses and modifies the resources. Resources can be TEXT FILES, HTML pages, images, videos or any dynamic business data. Each resource is identified by URIs/ global IDs. REST can use various representation to represent a resource like text, JSON, XML. Though in Spring Boot Microservices applications, JSON is the most popular one used.

RESTful web services developed by applying REST architectural concept.

RestTemplate is the core class for accessing Spring RESTful web services from the client-side. It communicates via HTTP server using RESTful constraints.

We can build RESTful web service in Spring Boot by adding ‘spring-boot-starter-web’ starter pack in the classpath. We can then create a controller class to define all API (URL) and REST operations like GET, POST, etc. This class should be annotated with @RESTCONTROLLER, making the class return the OBJECT. In case we want to convert the response to JSON format then we need to add Jackson to the classpath. Along with Spring Boot’s embedded Tomcat server, we can have the REST server running via the application JAR.

@RequestMapping: This annotation is used on methods in the controller class to specify the API path and the REST operation type via RequestMethod. This method will be responsible for serving the HTTP request to the given path and RETURN the desired response with the help of desired service classes.

Example:

@RequestMapping(path = "/contract/1.0/contracts", method = RequestMethod.PUT)

@RequestBody: This annotation is used to bind the incoming HTTP request body to the parameter defined in the method annotated with @RequestMapping. SPRING uses HTTP Message converters to convert the HTTP request body into a defined domain object

@PathVariable: This annotation is used to get the value from the HTTP URL and capture into the method arguments.

Example:

@RequestMapping(path = "/products/{id}",produces = "application/json")

@RequestParam: This annotation is used to capture values from the HTTP URL based on keys defined in the methods. Spring parse the request parameters and put the appropriate ONES into the method arguments.

Example:

@RequestMapping(path = "/products/{id}",produces = "application/json")

public Product getPlan (@PathVariable("id") final String planId,

@RequestParam(value = "q", required = false) final String queryParameters)

While defining a bean, Spring allows us to declare the scope of that bean. The scope describes the life cycle and visibility of that bean in the APPLICATION context.

Spring framework supports five scopes with the default scope as a singleton.

The scope can be described using @Scope annotation on any spring bean:

@Service

@Scope("singleton")

public CLASS ServiceImpl implements Service

Singleton:

When a bean is defined with a scope as Singleton, then the container creates only a single instance of that bean. A single object instance is cached and returned for all subsequent requests for this bean. On making any modifications to the object will be reflected in all references to the bean. This is the default scope when no other scope is specified.

However, the singleton scope is one object per Spring container only. So, if we have multiple spring containers running on a single JVM, then there can be multiple instances of the same bean.

PROTOTYPE:

A bean defined with prototype scope will return a different instance of an object, every time it is requested from the container. If a bean contains a state, it is recommended that you use the prototype scope for it. It can be defined by setting the VALUE ‘prototype’ to the @Scope annotation in the bean definition. We should use this scope when the object is not usable after a request is completed or requires certain state for each new request.

Caching is a mechanism that helps in REDUCING roundtrip calls to Database, REST service, files, etc. Performance under heavy load is a key feature expected from any modern web and mobile application, hence caching is really vital to enhance the speed of FETCHING data.

Spring Boot provides a STARTER project for caching “spring-boot-starter-cache”, adding this to an application brings in all the dependencies to enable JSR-107 (JCACHE - Java Temporary Caching API) and Spring caching annotations.

In order to enable caching in a Spring Boot application, we need to add @EnableCaching to the required configuration class. This will automatically configure a suitable CacheManager to serve as a provider for the cache.

Example:

Now to enable caching, we need to add a @Cacheable annotation to the methods where we want to cache the data.

@Bean is used when we WANT to define a class method as a Spring bean producer. It is used in conjunction with a configuration class (annotated with @Configuration). Here we explicitly declare the Spring beans.

On the other hand, @Component is used in classes, marking it as a source of bean definitions. However, it only works when we enable component scan in the application and the given class is included in it. So, in this case, we let Spring pick up the bean.

Now the end-result for both annotations is the same as Spring will add the beans the context.

However, there are some minor characteristics that can be considered while choosing between @Bean and @Component. Let us CONSIDER a scenario where we have a module containing few utility services, that are being shared across multiple applications. Though these services provide nice features, not all of them are needed by each application.

Here, if mark these utility service classes as @Component and set them for component scan in the application, we might end up detecting more beans than necessary. In this case, we either have to adjust the filtering of the component scan or provide configurations where even the unused beans can run.

In this scenario, it would be BETTER to use @Bean annotation and only instantiate the beans, that are REQUIRED INDIVIDUALLY in each application.

In a nutshell, we should use @Bean for adding third-party classes to the context, whereas @Component when it is inside the same application.

Circular Dependency in Spring is a situation when a bean depends on another bean, but at the same time, the other bean depends on the first one in turn.

Now when the Spring context is trying to load all the beans, it tries to create beans in the order needed for them to work COMPLETELY. For EXAMPLE, if we have an application with three beans where bean X depends on bean Y and it depends on bean Z. Spring will create beans in a sequence where bean Z is first created, then create Y with Z been injected to it and FINALLY create X with Y being injected into it.

bean X > bean Y > bean Z

But, in case we have a circular dependency, where bean X depends on bean Y; but Y, in turn, depends on X again.

bean X > bean Y > bean X

Here Spring is unable to determine which bean should be created first since they depend on one another. In this case, Spring will throw a BeanCurrentlyInCreationException while loading the Application context. It can happen if dependencies are not defined properly while using CONSTRUCTOR injection as it requires to create and load all the dependencies while loading the context.

Workarounds:

1. Redesign:

An appropriate redesign of the components in a manner that their hierarchy is well designed can avoid circular dependencies.

1. Use @Lazy:

1. Use Setter/Field Injection:

As setter-based injection loads the dependencies only when required; can help in avoiding error due to a circular dependency.

Hibernate is a JPA (Java Persistence API) implementation providing ORM (Object-relational MAPPING) for mapping, storing, updating and retrieving application data from relational DATABASES to Java objects and vice versa. Hibernate maps Java classes to database tables and from Java data types to SQL data types, hence programmer is relieved from WRITING traditional data persistence programs like SQL.

Whereas SPRING Data JPA is a JPA Data Access Abstraction used to significantly reduce the amount of boilerplate code required to implement data access layers for various persistence stores. With Spring Data, we still need to use Hibernate, Eclipse Link, or any other JPA provider. One of the key benefits is that we can control transaction boundaries with the use of @Transactional annotation.

A profile is a feature of Spring framework that allows us to MAP the beans and components to certain PROFILES. A profile can be assumed to be a group or an environment like dev, test, prod, etc.; that needs a certain kind of behavior and/or requires to maintain distinct functionalities across the profiles. So, when the application is running with ‘dev’ (Development) profile only certain beans can be loaded and when in ‘prod’ (Production) certain other beans can be loaded.

In Spring Boot we use @Profile annotation to map bean to a PARTICULAR profile by taking the names of one (or multiple) profiles.

Let’s say we have a COMPONENT class that is used to record and mock the REST requests and responses. However, we want to activate this component only in dev profile and disable in all other profiles. We annotate the bean with “dev” profile so that it will only be present in the container during development.

Profiles are activated using application.yml in the Spring project:

To set profiles programmatically, we can also use the SpringApplication class:

Swagger is a specification and framework implementation for producing a visual representation of RESTful Web Services API. With the help of Swagger, the API consumer can understand and interact with the remote service with a minimal amount of implementation logic. One can compare it to the blueprint of a house.

It creates a contract for the RESTful API, detailing all of its resources and operations in a human and machine-readable format. It allows the documentation to be placed at the same project as the server allowing easy development, discovery, and INTEGRATION of the application.

It is typically defined in a YAML file, which makes it easy to comprehend both by developers, API CLIENTS, and business users, ETC. Swagger can be integrated with Gradle for enabling code generation FEATURE, which is used for generating REST controllers and domain CLASSES (POJO) for the application. This helps in maintaining the API definition and code always in sync.

Below code STRUCTURE represent the ControllerAdvice  class developed using spring boot framework to handle the  exception.

1. Rest controller class which generate the exception

Below code structure represent the Rest Controller class developed using spring boot framework which use to ACT as Http Delete method.

Below code structure represent the Rest Controller class developed USING spring boot framework which USE to act as Http Put method.

Below code structure represent the Rest Controller CLASS developed using SPRING boot framework which use to act as HTTP POST method.

Below code structure represent the Rest Controller class developed using spring boot FRAMEWORK which use to act as Http Get method.

Below code structure REPRESENT the main method of spring boot which use to kick start the spring boot application along with the configuration details which is in annotated form.

To run the above code, we have to run the below command either from command prompt or shell: mvn spring-boot: run

INTERCEPTOR is one of the prominent features of spring boot and must use the @COMPONENT annotated class that supports it and it should implement the HandlerInterceptor interface.

There are three methods which are USED to implement the interceptor.

• preHandle() method − This method is predominantly used  to perform the operation by intercepting the call and getting the information present in the REQUEST.
• postHandle() method − This method is used  to perform the operation by intercepting  the call information present in the response.
• afterCompletion() method − This is used to perform OPERATIONS when the request and response get completed.

Spring boot checks if any CLASS is annotated as @ControllerAdvice and @ExceptionHandler and called from rest end point layer, when any exception occurs than spring boot calls the corresponding annotated class to handle the error MESSAGE.

• Spring boot provides the below annotation to create the CUSTOM handler which eventually catch the exception from rest endpoint.
• Spring boot provides the cross-cutting concern to handle the exception being generated by rest layer.
• Leverage to use the error message CODE comprehensively. 
• @ControllerAdvice is an annotation, to handle the exceptions globally.
• @ExceptionHandler is an annotation used to handle the specific exceptions and sending the custom responses to the client.

The real-time scenario is like, let’s say that most of the exception message is system generated and has a straightforward information, which is sometimes difficult to interpret by the user interface and understand by layman user, to solve this issue spring boot handle the error message and convert into the meaningful and comprehensive message which easy to understand and interpret. 

Swagger is a set of open-source tools that helps with creating documentation for your REST services.

This is something you can ATTACH to your methods exposing REST endpoints.

To enable Swagger into your application , you will need the following configuration :

Start the application and to test the application, go to the following URL in the browser :

http://localhost:8080/hello?name=John

It should print “Welcome to an Event @ Singapore”.

For checking the generated Swagger documentation, open this URL in the browser :

http://localhost:8080/swagger-ui.html.

In the majority of cases, you will build a Spring BOOT application using Spring Boot Starter Parent. However, there could be a case where you need to be very explicit about your dependencies and maven configuration. This could be a case of CORPORATE RULES or policies.

In such cases, you may use scope=import to get the benefit of dependency MANAGEMENT intact. For example,

Now include the required entries in dependencyManagement section before spring-boot-dependencies .For example,

The next step is we need to add an entry in the dependencyManagement of your project before the spring-boot-dependencies entry. For example, you could add the following element to your pom.xml:

When you generate a Spring Boot Project, you will see following inside your pom.xml file:

This is reference to default Spring Boot Starter or parent Spring Boot Starter. You can use multiple child Projects using the configuration from this. This Starter gives you for free Configuration ( For example,Java Version) , Version of Dependencies ( Dependency MANAGEMENT) and default configuration for plugin.

With parent Project, you get the following features : 

• Default Compiler Level for Java Version.
• Plugin configuration (exec plugin, Git commit ID, and shade).
• UTF-8 SOURCE encoding.
• A Dependency Management section: This is coming from spring-boot-dependencies pom, that manages the versions of common dependencies.
• Resource filtering.
• Resource filtering for application.properties and application.yml including environment-specific files (for example, application-dev.properties and application-dev.yml).

Spring Boot Starter Parent has spring-boot-dependencies as the parent pom. It inherits dependency management from spring-boot-dependencies.

Minimum Java version is 8 with Spring 2. 

You Can configure the VARIOUS properties/configuration as under :

Spring Boot Starter Parent specifies the default configuration for a host of plugins including maven-failsafe-plugin, maven-jar-plugin, maven-surefire-plugin, and maven-war-plugin ETC.

You can use logging with SPRING Boot by specifying log levels on application.properties file.

Spring Boot, by default, incorporates spring-boot-STARTER-logging as a transitive reliance for the spring-boot-starter MODULE. By default, Spring Boot incorporates SLF4J with Logback usage.

Presently, if Logback is accessible, Spring Boot will pick it as the logging handler. You can undoubtedly arrange logging levels inside the application.properties document without making logging SUPPLIER explicit setup files, for example, logback.xml or log4j.properties.

For example, the configuration is : 

logging.level.org.hibernate=ERROR

logging.level.org.springframework.web=INFO

If you would like to include Log4J or Log4j2, instead of Logback, you can exclude spring-boot-starter-logging and include the respective logging starter, as follows:

You will need to add log4j.properties file to the root classpath, Spring Boot will automatically pick it up.

With log configuration, you may see the following THINGS:

• Source Class name
• Thread Name /ID
• Date & Time
• Log Level ( Debug/Trace/Info/Warn/Error)
• Actual Log Message

• spring-boot-starter-actuator: This starter is very useful and will be used most especially when you are developing microservices etc. This provides production-ready FEATURES to HELP you monitor and manage your application. It provides a lot of inbuilt ENDPOINTS, for example, health ENDPOINT, /env endpoint.
• spring-boot-starter-web: Starter for BUILDING web, including RESTful, applications using Spring MVC. Uses Tomcat as the default embedded container
• spring-boot-starter-data-jpa: This is for using Spring Data JPA, default vendor is hibernated however you can override it to some other vendor, for example, ibatis.
• spring-boot-starter-data-MongoDB: Starter for using MongoDB document-oriented database and Spring Data MongoDB.
• Spring-boot-starter-thymeleaf: Starter for building MVC web applications using Thymeleaf views
• spring-boot-starter-security: Starter for using Spring Security.
• spring-boot-starter-test: Starter for testing Spring Boot applications with libraries including JUnit, Hamcrest and Mockito

Spring Boot Admin is a web application that is used for Spring Boot applications management and monitoring. Each application is considered a client and registers to Spring Boot Admin Server. The Spring Boot Actuator endpoints give the magic behind the SCENES.

With this, what you get for free is @EnableAdminServer, so let’s use this.

This sets up our admin server.

Start the Admin Server and see if it is available at localhost:8080/admin/

Now, in your client application , we need a corresponding client which will register to this admin server. Use following in your client application.

Now on the client SIDE, you also need to provide the url where admin server is running. Configure following in your client application’s application.properties:

spring.boot.admin.url=http://localhost:8080

Spring Boot Admin can be configured to only show the data we deem helpful. We just need to change the default setup and add our own required metrics.

For this configure following in application.properties of Spring Boot Admin Server.

spring.boot.admin.routes.endpoints=env, metrics, trace, Jolokia, info, configprops

AMQP is a platform-independent protocol. Spring Boot provides Starter for AMQP spring-boot-starter-amqp.

With this starter imported, if you have RabbitMQ running , Spring Boot will auto configure connection to RabbitMQ from your application. If you want to customize the configuration, you can use:

spring.rabbitmq.host=localhost

spring.rabbitmq.port=5672

spring.rabbitmq.username=admin

spring.rabbitmq.password=secret

Additional Properties for Retry :

spring.rabbitmq.template.retry.enabled=true

spring.rabbitmq.template.retry.initial-interval=2s

You can use AMQPTemplate or RabbitMessagingTemplate for sending messages similar to JMSTemplate. For receiving messages, you can use

If you want to override DEFAULT Connection Factory, you can make use of SimpleRabbitListenerContainerFactoryConfigurer as follows :

In this case , your listener will be changed to :

Spring Boot offers a number of features with respect to Messaging. To start with let’s talk about javax.jms.ConnectionFactory.

1. Using ConnectionFactory

This provides an Interface to send & receive MESSAGES.

Spring uses JNDI to LOOK for the ConnectionFactory which you can configure by using the following property in APPLICATION.properties :

Alternatively, if ActiveMQ Starter is used, Spring Boot will autoconfigure the factory. You can customize the configuration using following properties :

How do you send & receive Messages?

To send a message , you can inject org.springframework.jms.core.JmsTemplate into your application bean and use it for sending messages.

For example,

You can convert a simple method into Message Listener by using annotation org.springframework.jms.annotation.JMSListener (destination =”myQueue”)

To override default Connection Factory,

you can make use of DefaultJmsListenerContainerFactoryConfigurer as follows:

Now your listener would be as follows :

@Component

public class SomeBean {

Hibernates gels well with Spring and with Spring Boot around, it makes the task super easy.  We will see a generic way of Integrating Hibernate using Spring Boot in such a way that switching to some other jpa vendor tomorrow would be super easy.

Let’s start with the process.

1. First thing first, you will need spring-boot-starter-data-jpa.

Since Spring uses Hibernate as default vendor, you really don't need to configure or mention Hibernate explicitly somewhere.

2. Second step would be Drafting the ENTITY Class. Let’s consider, we are building an application to get a list of employees. So Employee, in this case, would be an Entity for us. You can use @javax.persistence.Entity annotation to DEFINE your entity as :

@Entity

public class Employee {

@Id

    @GeneratedValue

private Long id;

private String name;

//……./// Getters & Setters

3. Extend the JpaRepository and define methods ( if required).

Your get all CRUD operations method inbuilt and if you need any additional customized methods, you can define them here.

In our example, we don't need to define any method as a JPA repository does provide findAll() method.

@Repository

public interface EmployeeRepository extends JpaRepository<Employee, Long>{

}

Actually, that’s it, you are DONE from an Integration point of view. Of course, you will need a few additional things from an OPERATIONAL point of view that we would define below. 

4. Table Naming in Capitals :

For this set following property in application.properties

spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

5. For Operational purpose in this example, we are using H2, so for that : 

  a) INCLUDE H2 maven dependency in pom.xml 

  b) Enable H2 by setting following property in application.properties 

spring.h2.console.enabled=true

6. Define EmployeeService :

 7. Include Spring-boot-web-starter in pom.xml abd Define EmployeeController :

The Code is available in GitHub @

Now Start the application and hit http://localhost:8080/h2-console

Change JDBC url to “jdbc:h2:mem:testdb”.

Leave others with default values and login and execute the following queries :

insert into EMPLOYEE values(1, ‘Virat’);

insert into EMPLOYEE values(2, ‘Rohit’);

insert into EMPLOYEE values(3, ‘Rahul’);

Now hit the http://localhost:8080/employees endpoint and see the list of employees just entered.

• Java VERSION: Spring Boot 2 requires Java 8 as a minimum version. Spring Boot 1 supports version Java 7 and below. From Spring Boot version 1.4.x, it requires Java 7 however lower versions of supports lower Java versions like Java 6 or so. As far as a recommendation goes, for Spring Boot 1, try to be at least on Java version 7 as much as possible. If you want to use the latest Java release and take advantage of this framework, Spring Boot 2 is the only option for you.
• Spring Version: If you want to use features of Spring 5, go for Spring Boot 2.
• BOM ( Bill of Materials): In Spring Boot 2, there has been an upgrade to the dependencies version, the whole list is available here, for example :
  • Gradle minimum version is 3.4
  • Tomcat - version 8.5
  • Hibernate - 5.2
• Security upgrade

With Spring Boot2, everything is secured, actuator endpoints as well as static resources.

• New Starters

New Starters for Reactive components like MongoDB, Redis, Cassandra.

• Spring Boot Actuator Upgrade

All endpoints are now under /actuator endpoint. You can tweak this path by using management.endpoints.web.base-path property.

All are disabled by DEFAULT( except /health & /info) . To enable you can use management.endpoints.web.exposure.include=* ( or list endpoints to be enabled)

You can easily write a new endpoint using @Endpoint annotation and it will get listed under /actuator.

For example,

SIMILARLY, we can use @EndPointWebExtension to extend an existing endpoint.

• Other changes: Gradle Plugin upgrade, most of the configuration start with management.

• For this, you will extend SpringBootServletInitializer 

• Packaging Type in pom.xml needs to be DEFINED as :

• Add spring-boot-starter-tomcat as the provided SCOPE

Spring Boot eases QUICK starting a new feature from an application DEVELOPMENT POINT of view. However, what about building, packaging and other life CYCLE steps of your Spring Boot application. Here, Spring Boot maven plugin comes to your rescue. 

It helps to collect all the jars on the classpath and builds a single, runnable jar ", which makes it more convenient to execute and transport your service.

It searches for the public static void main() method to flag as a runnable class.

The Spring Boot Plugin has the following goals.

• spring-boot:run: This is for running your Spring Boot application.
• Spring-boot:repackage: This is for repackaging your jar/war to be executable.
• spring-boot:start and spring-boot:stop: This can be used for Integration tests.
• spring-boot:build-info: This generates build information that can be used by the Actuator.

For Class level conditions, you can have @ConditionalOnClass and @ConditionalOnMissingClass. The @ConditionalOnClass and @ConditionalOnMissingClass annotations let @Configuration classes be included based on the presence or absence of specific classes. For example, using these conditions, Spring will only use configuration MyConfiguration bean if the SomeClass is present on the classpath:

Similarly, in the following example, Spring will only use configuration MyConfiguration bean if the SomeClass is absent on classpath:

Similarly, there is something called, @ConditionalOnBean and @ConditionalOnMissingBean. If the beans specified as PART of this annotation are available on classpath then class will be considered for Configuration.

Here MyBean will be created only if dependentBean exists on classpath, this is very useful to create bean in ApplicationContext.

Here if myService bean will be created only if no existing my service bean exists in ApplicationContext.

@ConditionalOnProperty

This tells Spring to INCLUDE Configuration based on PROPERTY value. This can come to rescue for defining environment-specific beans.

In the following example, the instance of MyBean will be created only if = local.

If you want to include configuration if a specific resource is present, then you can use @ConditionalOnResource is present.

The @ConditionalOnResource annotation lets configuration be included only when a specific resource is present:

Let’s consider a situation, where you WOULD LIKE to include a particular configuration only if the application is a web application. In such cases, you can use @ConditionalOnWebApplication annotation.

Similarly, we have @ConditionalOnNotWebApplication which can be used to include configuration if the application is non-web application.

We have seen various @Condition annotation which are for specific use cases. If we have a general and more complex requirement, we can make use of @Conditional annotation & 

Spring Boot OFFERS different ways of running an APPLICATION.

These are :

Running the Application as Spring Boot Application

By Packaging the application as War application and deploying it to an external Tomcat WEB server.

java -jar target/mydemoapp.jar

To Support remote debugging for this, you can use the following parameters along with the java command :

java -Xdebug -Xrunjdwp:server=y, transport=dt_socket, address=8000,suspend=n \ -jar target/mydemoapp.jar

mvn spring-boot:run 

You can use the MAVEN_OPTS environment variable

export MAVEN_OPTS=-Xmx1024m

gradle bootRun

You can use JAVA_OPTS environment variable

export JAVA_OPTS=-Xmx1024m

You can use @SpringBootTest annotation. This is over and above the spring-test module. When you include @SpringBootTest, applicationContext is started.

SpringBootTest supports different modes, you can enable anyone of them by using web environment property along with @SpringBootTest. These modes are :

• RANDOM_PORT: This is providing the real environment. The embedded SERVER is started and listen on a random port. This is the ONE should be used for the integration test
• DEFINED_PORT: Loads a WebServerApplicationContext and provides a real web environment.

These TWO modes are important from an Integration point of view, other modes supported are :

• MOCK: This is the default mode. Here it  loads a web ApplicationContext and provides a mock environment
• NONE: Loads an ApplicationContext by using SpringApplication but does not provide any web environment

For example, if you go for RANDOM_PORT, code will look LIKE :

@RunWith(SpringRunner.class)

@SpringBootTest(web environment = SpringBootTest.WebEnvironment.RANDOM_PORT)

public class YourTestClass

@MockBean : 

You can make use of @MockBean to mock a particular service or repository or some bean.

For example,

Using  MockMvc &AMP; @AutoConfigureMockMvc: 

You can mock up the http requests using MockMvc & @AutoConfigureMockMvc

For example,

Spring Boot LETS us define Application Properties to support us for work in different environments. These properties include parameters like application name, server port number, data source details, PROFILES, and many other useful properties. Spring Boot supports YAML based properties configurations to RUN the application.

We can simply put an “application.yml” file in “src/main/resources” directory, and it will be auto-detected.  So, by using this default file, we don’t NEED to explicitly register a PropertySource, or provide a PATH to a property file, unlike native Spring where we have explicitly define them.

A sample application.yml file looks like below:

Spring Boot provides ‘spring-boot-devtools’ module with features that help the programmers while developing the application. It basically improves the experience of developing a Spring Boot application. One of the key features is AUTOMATIC reload of application as soon as there is a change; hence developer does not NEED to STOP and start the application each time. The is an intelligent feature as it only reloads the actively developed classes but not the third-party JARs.

Another key feature is that by def,ault it disables the caching of view templates and static files. This enables a developer to see the changes as soon as they make them.

In CASE, we want to DISABLE any of these features, then we need to set them in an application.yml file. For example -Dspring.devtools.restart.enabled=false will avoid automatic application restart.

Below are a few of the features provided:

1. Property defaults
2. Automatic Restart
3. Live Reload
4. Global settings
5. Remote applications

Aspect Orientated Programming (AOP) is a mechanism for adding certain behavior by virtually breaking the program logic into distinct parts called concerns. This helps in increasing modularity by cross-cutting the concerns. These cross-cutting concerns SPAN across multiple points of an application and are conceptually separate from the application's BUSINESS logic. For e.g. transaction management, authentication, logging, security, etc.

It is a concept in contrast to OBJECT Oriented Programming (OOPS) and Dependency Injection (DI).

The key unit of modularity in OOPS is the class, whereas in AOP the unit of modularity is the aspect. DI allows the application to decouple the objects from each other and AOP helps to decouple cross-cutting concerns from the objects that they affect.

Spring AOP module provides interceptors to intercept an application. For example, when a method is executed, we can add custom functionality before or after the method is executed.

Below are few important AOP concepts:

• Aspect: It is a concern that we are TRYING to implement like logging, transaction management.
• Advice: It is the specific ACTION that needs to be done i.e. the code to be executed.
• Pointcut: It is the expression which determines the methods on which Advice should be applied.

Yes, we can create our own custom starters. For instance, if we have an internal LIBRARY for USE within the organization which is used ACROSS multiple PROJECTS. Then it would be a good practice to create a starter for it and to be used in Spring Boot CONTEXT. These starters enable developers to avoid lengthy configuration and quickly jumpstart their development by the use of simple annotations. To create our own custom starter, we require to create an auto-configuration class with an auto-configure module and a starter module which will bring all required dependencies using pom.xml or build.gradle. Spring Boot custom starter have certain guidelines for the naming convention. They should not start with Spring Boot and ideally, have a name like “name-spring-boot-starter”.

Below are the significant annotations used for connecting a database with Spring application:

• @Repository: This annotation is a specialization of the @Component annotation i.e. automatic component scanning enabled so that Spring imports the beans into a CONTAINER and inject to dependencies. It is typically used on the DAO (Data Access Object) classes. It also catches persistence related exceptions and rethrows them as Spring’s unified unchecked exception.
• @Entity: This annotation is used to indicate that the class is a JPA entity and their state is managed by the underlying Persistence Context. In case @Table annotation is not added, it is assumed that this entity will be mapped to a table, with the same name as the class.
• @Table: This is used to map the entity class to a given table. It allows having two different names for the Java class and the Database Table.
• @Id: This annotation is added on a field that captures the object ID and is an IDEAL CANDIDATE for the primary key
• @Column: This is used to explicitly define the column name, default is field/property name.
• @Transactional: It is convenient, readable and recommended an approach to handle TRANSACTIONS in Spring. This annotation defines the scope of a single database transaction, that happens inside the scope of a persistence context. The persistence context is in JPA the EntityManager, with default implemented of Hibernate Session.

The IDEAL approach to implement Exception Handling in Spring Boot is by using @ControllerAdvice annotation. It ALLOWS the multiple scattered @ExceptionHandler to be consolidated into a single global error handling component. It allows full control over the body of the response as well as the status code by use of ResponseEntity. It allows to handle and define the behavior of SEVERAL exceptions in the same class so that there is a common source of all application errors. It also allows to map different errors to the same method if desired.

@ExceptionHandler annotation provides a mechanism for handling and defining behavior for the exceptions thrown during the execution of handlers (Controller OPERATIONS).

@ResponseStatus is used to mark a method or exception with error status code and reason that should be returned to the client. The status code is applied to the HTTP response when the handler method is invoked, or whenever said the exception is thrown.

Example:

Spring Boot Actuator provides the ability to inspect the internals of an application at runtime. It provides application data on auditing, metrics, bean details, version details, CONFIGURATIONS, logger details via REST (HTTP) endpoints. These endpoints help in monitoring and managing a Spring Boot application in production. We can also add custom endpoints apart from the default 16 provided. HOWEVER, it should not be considered as a replacement for production-grade monitoring solutions though it provides a great starting point.

The Actuator endpoint acts as a root for all other endpoints: http://localhost:8080/application

Below are a few of the significant endpoints exposed:

1. Environment details:

This endpoint provides information about the operating SYSTEM, JVM, installation, system environment variables, and the values configured in application properties files.

1. Health:

This service provides details of the disk SPACE and status of the application.

1. Beans:

This endpoint provides the details about all the beans that are loaded into the Spring context. It provides details like name, scope, type, location, and dependencies of the Bean.

1. Metrics:

This endpoint shows metrics about Server memory, processors; JVM details like a heap, threads, garbage collection, etc.

1. Debugging:

Below actuator endpoints are exposed for debugging application:

@SpringBootApplication is the primary annotation which needs to be added to the Application class or the MAIN class to the project and enables features like JAVA-BASED Spring configuration, component scanning, and auto-configuration. An Application class is used to BOOTSTRAP and launch a Spring application from a Java main method. This class automatically creates the ApplicationContext from the classpath, scan the configuration classes and launch the application.

@SpringBootApplication is essentially a combination of below annotations:

• @Configuration: is used to mark a class as a source of bean definitions.
• @ComponentScan: is used to have Spring scan the package for @Configuration classes.
• @EnableAutoConfiguration: to enable Spring to determine the configuration based on the classpath.

Following parameters are accepted in the @SpringBootApplication annotation:

• exclude: This is used to exclude the list of classes from the auto configuration.
• excludeNames: To exclude the list of fully qualified class names (class names with package info) from the auto configuration.
• scanBasePackageClasses: To notify Spring the list of classes that has to be applied for the @ComponentScan.
• scanBasePackages: To provide a list of packages that have to be applied for the @ComponentScan. 

Example: