NH:STA S01E05 Log4j posted Tuesday, August 5, 2025 by The Neighbourhoodie Team announcementnews
This post is part of our series on our work for the Sovereign Tech Agency (STA), formerly the Sovereign Tech Fund. Our introduction post explains why and how we are contributing to various Open Source projects.
In this episode, we look at migrating test suites, cover that infamous vulnerability and speak to Alba Herrerías Ramírez and Julia Krüger about their work on the project.
Introducing Apache Log4j
Apache Log4j is an open source Java library for logging. It’s among the most well known, if not the most well known, of its kind, something its 300+ contributors would attest to. In 2022, 49% of devs worldwide when surveyed responded that they use Java, and if Log4j is the logging utility of choice, you have a rough idea of how widely deployed this library is. It may not be the only reason you’ve heard of it — but we’ll get to that later.
Logging — documenting events including messages, errors or data in the sequence they occurred in either your operating system or software — is indispensable for devs and QA teams when it comes to understanding actual behaviour and reproducing incidents. When it’s installed on your Java application, Log4j lets you see your app’s processes and get helpful messages about them.
As hinted, if you’re already familiar with Log4j, your first introduction may not have had anything to do with a need to find a logging library for your own project. Log4j was famously the subject of Log4Shell, a notable catalyst for governments to invest more in open source resilience.
CVE-2021-44228, better known as Log4Shell, was reported in November 2021. It had lain undetected since 2013; long enough for the version with the vulnerability to circulate onto the world’s biggest servers, arguably potentially affecting most of us. We’re indebted to the Apache team who worked 24/7 in order to eliminate the threat this vulnerability posed quickly. It’s also hard not to be grateful for the impact it had outside of just this project — it’s no coincidence that the Sovereign Tech Agency was successfully founded and funded the following year.
What We Worked On
If you’ve been following our work, you’ll know that we’ve gotten quite practiced at joining and assisting teams quickly. To be independent and get up to speed without many resources or help from the core team, we start at the beginning and get the app running locally using contributor instructions. Their docs were excellent. We had no notes.
The Log4j project uses JUnit for their testing suites — a tool loved for its unit tests in particular. The Log4j codebase contained a mixture of JUnit4 and JUnit5, so their team asked if we could take over the migration they started. We had our scope: we’d focus on testing, and deliver the upgrade to JUnit5. This also meant we didn’t need to fully learn the entire codebase to contribute. If you’ve done a migration, you’ll know it can be time-consuming, so we were excited to take this off the team’s hands. Not only can we contribute to raising the codebase quality even further and strengthening the project, it’s unlikely to be the kind of work that introduces a big bug someone needs to take care of later. Double win!
Every time the Neighbourhoodie team switches to a new language we’re not already experts in, we need to get familiar with the idiosyncrasies of the environment that these languages have around them. Refactoring is a great way to get familiar with a project, and adding test coverage even more so. In open source projects, extensive test coverage both keeps projects resilient and also makes them more approachable for contributors.
With Log4j, we needed to learn how the tests work, and how the libraries work so we could ensure we completed the migration without breaking changes. In all, five members of our team worked across 14 modules on a dozen PRs. At the time of writing, most of our PRs have been merged, introducing around ~5700 lines of refactored code.
Reflections from the Team
Alba and Julia sat down with us to talk more about their experience working on Log4j.
What surprised you the most about this project?
Alba: For me this project was particularly great because I dealt with the management side. Of course I did a lot of development, but I managed the engineering team. As we saw, working with five people meant there was quite a heavy coordination and management load. I was very happy that so many people joined and so many people could contribute to the project while we were working on it.
Julia: It was great to have so many people working on a project at the same time. If someone encountered a problem, chances were high that somebody else already worked out a solution a day prior for something similar. In most of our STA projects we’ve worked in smaller groups, so this was refreshing.
What was especially challenging about this project?
Alba: Definitely working with a huge codebase, structuring the work with a big working group, and managing contributions with our workflow. At times the modules being refactored were related, so changes needed to be made simultaneously. Contributors outside of Neighbourhoodie also started working on the modules we were working on. Some of those changes were merged before ours, and in one case we did end up with quite a few conflicts. Sorting out the conflicts was a bit of a challenge, but it was great to see people so keen to contribute.
Julia: Agreed, there were a lot of things happening with this project. Since we’re in the EU and the project’s maintainer base is global, timezones also played a role; sometimes you’d wake up to hundreds of changes. You need to check what was merged overnight in case it affects the tests you’re writing. It’s a very active project, which means there was always something to do and we didn’t spend a lot of time waiting for responses. We’re particularly thankful to a handful of the maintainers based in Poland, who reviewed a lot of PRs in our timezone while we were at it.
Conclusion
Maintainers of the package will hopefully enjoy our work most as they breathe a sigh of relief and move off JUnit4. We’re grateful to the team for their support when we needed it, and we’re very proud we could contribute to reduced technical debt in one of the internet’s most deployed projects.
You can read more about our work with the Sovereign Tech Agency and the projects we’ve worked on with their support:
« Back to the blog post overview