NH:STA S01E05 Log4j

This post is part of our series on our work for the 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

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 , 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 was successfully founded and funded the following year.

Our contributions

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 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 .