When I’ve first learned that there is something more than printing things to console log4j was state of the art solution. Then SLF4J joined the party and improved where log4j was lacking. The new version of LOG4J is available for some time already and I didn’t have a chance to look at what if offers. Let’s examine what’s possible with the second version of a very well known logging library.
Sometimes it’s good to have an option to try something out on the live environment. Checking things against production like traffic is the most reliable way to gather real-life metrics. In this post, I’m going to try and set up spring cache with a toggle. It’ll be possible to turn it off and on during application runtime possibly using external toggle service.
Some time ago we had a problem with performance caused by generating big reports for users. During one of the firehouse meetings, there was an idea to generate reports from the replica database. We’ve solved the issue differently but the idea got me interested. In this post, I’ll configure spring-boot based application to use the replica database for all read-only transactions.
You probably already know that by default in spring transactions are rolled back only for runtime exceptions. When a checked exception is thrown from your code and you don’t explicitly tell spring that it should rollback the transaction then it get’s committed. In this post, I’m going to create simple reference material on when transactions are rollback when using Spring and Lombok.
If you are not working with multithreading programming and don’t have to test any asynchronous code then this post will probably do you nothing good. But if you have ever struggled with testing some logic running in multiple threads and you don’t know Awaitility. A small library helps testing asynchronous code. If you’ve never heard of it then you should continue reading.
Mocking library is an important tool in every developer toolbox. Sometimes you want to do things that at first glance look a bit more complex than returning number 42 from some method. Let’s see what stubbing techniques are available in Mockito out of the box and what they offer.
We are improving cache in the project Im working on. In the code base I’ve found a method which accepted a collection of ids and returned collection of objects for those ids. My goal was to add cache on individual values returned by the method. Creation of items was IO heavy and time-consuming operation so removal of cache was not an option.
In the past, I’ve implemented couple of tests that aimed to verify naming conventions or some other practices team agreed upon. And presented a way how to ensure they are followed. When I’ve been writing those I was not aware that there is a library that aims to test architecture conventions - ArchUnit in this post I’ll write a simple test case to check what’s possible out of the box.
Recently I’ve found a very interesting project which allows to spin up docker containers for test purposes. Writing tests checking integration with external services is not an easy task. With testcontainers library it gets simpler because you can have external service up and running just for your test in a couple of lines of code.