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.
When the whole team agrees on coding standards we tend to be optimistic. We think that from now on everything will be exactly as we decided. The truth is that usually after a couple of months you’ll reinstall IDE or system and forget about configuration or new people join and it’s the Wild West all over again.
Spring provides many easy to use abstractions and you use many of them without even knowing about them. You probably know that in order to have @Transactional or @Cacheable annotation work spring creates proxies for you (sometimes proxies on top of proxies…), but have you ever wondered how it’s happening under the hood? What Creation of object proxies is a cumbersome task. One has to decide if the proxy should be created using native java mechanisms (JdkProxy available only on interfaces) or using cglib and it’s complicated interfaces.
How beans are registered in spring and what is the base of beans creation, how to extend spring’s context to our needs? In this post, I’m going to dig into the foundation of many mechanics in spring framework - bean definition.
Have you ever wondered how spring does things? How field annotated with @Autowired is populated?
How asynchronous or scheduled methods are discovered. In this post, I’m going to take a deeper look
and scratch a bit on the surface of spring internals. I’ll focus on BeanPostProcessor interface
which can be used to achieve interesting things and is used in many various functionalities across
spring framework itself.
Some time ago I’ve started working on updating automated tests written in selenium with java. After working a bit with it I’ve noticed that from time to time constructing XPath expression can get ugly. We are writing our tests in pure java and "ugliness" usually comes from string concatenation when some extra parameters must be taken into account. I’ve decided to write something that might help a bit with building XPaths without string concatenation.
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.