SivaLabs

If you ever worked on a large project which doesn’t have any tests then you know how painful it is to work on such codebase.

You know what is more painful? Working on a project which has plenty of USELESS tests written for the sake of passing minimum code coverage requirement.

I was working on a SpringBoot application which is planned to deploy on AWS and, we were using S3, SQS and RDS services.

LocalStack provides an easy-to-use test/mocking framework for developing AWS based Cloud applications.

Nowadays software development is a challenging task as the number of programming languages, frameworks, libraries are increasing rapidly day by day. Luckily, the number of resources to learn on the internet for free also increased a lot. There are a ton of free resources to learn almost everything on the internet. There are lots of official documentation, blog posts, Udemy courses, YouTube videos etc.

Spring Boot is the most popular tech stack for building Java-based REST APIs. In this tutorial, we will learn how to write tests for Spring Boot applications.

• Create SpringBoot Application
• Unit Testing using JUnit 5 and Mockito
• Integration Testing using TestContainers
• Testing MicroService Integrations using MockServer

In the previous post Kafka Tutorial - Java Producer and Consumer, we learned how to implement a Producer and Consumer for a Kafka topic using the plain Java Client API.

In this post, we are going to look at how to use Spring for Kafka, which provides a high-level abstraction over the Kafka Java Client API to make it easier to work with Kafka.

In the previous article, Introduction to Spring Cloud Config Server, we have seen how to use Spring Cloud Config Server.

But the problem is that to reload the config changes in Config Client applications, we need to trigger the /refresh endpoint manually. This is not practical or viable if you have a large number of applications.

Spring Boot provides a lot of flexibility in externalizing configuration properties via properties or YAML files. We can also configure properties for each environment (dev, qa, prod, etc.) separately using profile-specific configuration files such as application.properties, application-dev.properties, application-prod.properties, etc. But once the application is started, we cannot update the properties at runtime. If we change the properties, we need to restart the application to use the updated configuration properties.

One of my blog followers sent an email asking me to show an example of “Real-World Usage of Spring AOP”. He mentioned that in most examples, the usage of Spring AOP is demonstrated for logging method entry/exit, Transaction management, or Security checks. He wanted to know how Spring AOP is being used in “Real Projects for Real Problems”.

So I would like to show how I have used Spring AOP in one of my projects to handle a real problem.

In the Java community, Spring vs. JavaEE is a never-ending debate. In such debates, people form two groups consisting of evangelists, architects, and hardcore fans of one platform and debate endlessly. Those who participate in the debates may be architects who are responsible for platform selection. But what would developers think about this Spring vs. JavaEE debate?

I am a Java developer who uses both Spring and JavaEE, and I am not part of the Spring or JavaEE fan club. Here, I would like to share my own thoughts on this epic Spring vs. JavaEE debate.

Maven is a good project management tool that greatly reduces the amount of time we spend creating Java projects with a proper structure. With so many predefined Maven archetypes, it is even easier to create projects by simply selecting the archetype based on the technologies we need and the type (jar/war/ear) of project we want to create.

However, sometimes those predefined archetypes’ structures may not suit our needs well, or we may need some more additions to the pre-configured dependencies/frameworks, etc.