The story is really simple. I wanted to accept my class as rest controller method param. I decided that I don’t want to convert a simple string to object every time and it would be faster if I do the conversion in the single place. After a quick research I’ve found Converter interface which looked like perfect for the job. After some digging and investigation it turns out that there is a lot of automagic in the Spring conversion service.
Most of the application we are working on are built around the data. Since the information is the core value of the application we store it in the persistent and reliable storage - database. Applications evolve in time so does the way we store the data. In this post, I’m going to present my experiences and thoughts on evolving database schema.
While investigating @EventListeners in spring I’ve noticed very interesting annotation - @DomainEvents. In this post I’m going to check what can be achieved using @DomainEvents annotation and how to effectively use it with old good JPA. Let’s start with short introduction to domain event idea if you are not yet familiar with it. Now let’s go back to the @DomainEvents annotation in spring-data. Spring-data by default provides support for this annotation and it’s complementary annotation @AfterDomainEventPublication.
Last time I wrote about events in a spring based application I’ve introduced some basics on how events can be dispatched using spring infrastructure. In this post, I’m going to dig deeper into an order of handlers, exceptions and asynchronous events handlers.
When I’ve got some free time I try to add new features to springmock. Lately, after adding some new stuff I realized that double definition parsing class has more than one responsibility (class parsing, naming, definition creation, etc). So I’ve decided it’s time to refactor it and split responsibilities into dedicated classes. Once I did that and tests in the shared kernel started to pass I executed mvn verify just to be sure that everything was working and it wasn’t…
We all know how inheritance works and implemented some kind of class hierarchy at least few times during our career. Some of us know already that inheritance is not the silver bullet. Some of us know that inheritance must not be overused and considered with caution. Now I’m going to show you how choosing the quick win might cost you some unexpected troubles in the future.
With spring 4.2 (released more than one year ago) serious improvements regarding embedded events were made. You probably already know it, but I’ve never had a chance to properly investigate it. Lately, when digging into code base of the system I’m currently working on I got an opportunity to see it in action and after quick glimpse, I decided to investigate it a bit further.
I’ve been using springboot for some time now, but there was that one thing that bugged me a lot. While writing integration tests with mocks you are forced to use mockito as the mocking library. That’s great and easy to understand if you are not using spock. The problem is that in spock there are better ways to mock stuff…
Some time ago I noticed new library in our code base - Random Beans which as the name suggests is a tool developed to easily create random data and random objects for testing purposes. Unfortunately, we used it in the wrong way. Here’s how we backed up from the random test data to regain control over testing.