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.
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.
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’ve been trying to dynamically create spring beans. After fast stackoverflow check I decided to drop it and go with something else. Lately I’ve been trying to implement more complicated bean registration mechanism in which skipping dynamic bean creation wasn’t an option. Here’s how you can create spring beans “from code”.
Working with a lot of data using plain JPA or hibernate or spring-data is possible, it does work and usually, it doesn’t require a lot of extra coding. Starting small is the fastest way of getting things done but you must be aware of few things that might shoot you in the foot.
A few days ago I’ve stumbled upon SQL query performance issue. Git claims that I was the author so maybe that’s the reason I remember this feature. There was like 3 classes, everything was super easy and super fast all I needed to do was to let Hibernate do its thing. Then time passed, new features were requested, the model becomes more complex, the number of rows increased to ~4 million and original query became too slow.
When working on query optimization I was really happy to find that detailed tests are in place. With proper test setup I was able to test my new query to make sure all requirements are met and then quickly copy paste query to sqldeveloper run it on a test environment and verify if performance is acceptable. It wasn’t simple query and it took me some time to figure out how to make it quick and work exactly as old one. That was the time I was really glad that we invested in detailed unit tests in the beginning.