Have you ever noticed a lot of default metrics Spring Boot with Micrometer generate for your app? If not - add actuator dependency to your project and hit /actuator/metrics endpoint where you will find useful info about jvm, process, tomcat, traffic and so on.
Then add some cache, data sources or jpa dependencies and even more metrics appear. If you ever wondered how they end up there and where can we found explanation about what params do they describe - this is a post for you.
In this article you will find basic information about change data capture and high level view of the Kafka Connect. Then see how one of the connectors (Debezium PostgreSQL) can work in standalone mode (without the platform) - moving CDC to another level of simplicity.
Some time ago I wrote a blog about how to configure CloudWatch metrics Spring Boot. It was all before micrometer and depended on Netflix Servo Metrics.
Time was slowly passing and civilizations prospered but it’s still difficult to find info on how to make Spring Boot work with Micrometer CloudWatch.
So here it goes.
Article explains the Spring Boot classloader (LaunchedURLClassLoader) and a way to temporarily override library classes with your custom ones.
Article explains how to send Spring Boot and Netflix Servo metrics to AWS CloudWatch.
Morover it describes mechanisms making it happen.
It also mentions problems I run into trying to do the same with Spring Boot and Spectator.
Spock rulez. Writing tests has never been simpler and more pleasant. All thanks to concise and informative syntax. But how is Spock syntax made possible?
From the dawn of time there is an ongoing discussion about using surrogate keys vs natural keys in your database tables.
I don’t want to take any side here - just write about one consequence you’ll face when persisting natural key entity with Spring Data repository.
The short answer is: go Lazy if you care about number of queries happening under the hood. “But what if I always need a particular relation?” - still go lazy, here is why.
Remember the times when we had to register dispatchers, viewResolvers, etc. to make our spring application web-app? Then there was @EnableWebMvc annotation and now even this is redundant.
These days the only thing you need to do is to add ‘org.springframework.boot:spring-boot-starter-web’ dependency to your project and everything else is done automagically.
Recently I’ve faced an interesting issue. Got transactional method saving entity to the database - method is called, no exception is thrown - but no data is stored into the db.
Amsterdam gave me a taste of everything - I guess this is what this city is about :).
Few days ago 4F company gave me an opportunity to participate in Spring I/O conference in Barcelona.
2 days, 4 rooms and 41 speakers presenting technologies behind, within and around most popular java framework.
Having some conference history, at some point I developed believe that at any given event, many presentations and lectures find their place in agenda only by mere accident. All the more I was curious how all of this will look under watchful (I hoped) eye of Pivotal.
Always hungry for changes, some time ago 4F company moved from Maven to Gradle.
Most of the migration work went relatively smoothly.
Surprisingly though, not every developer was eager to sacrifice his precious time on something as trival as build tools and
with rapid googling for example based knowledge some mistakes were made.
One of them can serve to decribe one of Gradle’s fundamental aspects - Build Phases.