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.
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.
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.
Optimistic locking is concurrency control method that allows to execute multiple transactions simultaneously as long as they don’t interfere which each other. That’s definition from wikipedia. You probably already know that Hibernate supports optimistic locking and all you have to do in order to implement optimistic locking in you app is to add @Version on number or timestamp field and you are good to go. Right?
Immutability and functional programming are hot right now. But how to achieve immutability with objects deserialized from json? Luckily there is pretty old feature introduced in jackson 2.7.0 which uses constructor based object creation and uses @ConstructorProperties (introduced in java7).