DEV Community: Oluwatimilehin Awoniyi

The Surprising Reason Your JSON Data is Returning null in Spring Boot

Oluwatimilehin Awoniyi — Wed, 19 Mar 2025 18:10:43 +0000

Introduction

Last week, I found myself in a debugging nightmare. My Spring Boot services were talking, but somehow, one of them was ghosting key data.

The amount field came through fine, but the ID? Completely missing.

It felt like my code was gaslighting me—until I found the culprit. And it was something so basic, yet so sneaky, that I had to share it.

The Problem: Why is JSON Returning `null`?

I had two Spring Boot services:

Service A (Client) → Sends a Payment object to another service.
Service B (Server) → Receives and processes the Payment object.

Here’s what was sent:

{
    "requestId": "5ea2aa99-4020-4d9f-9d1f-1737d5df2a6e",
    "amount": 15.0
}

But Service B expected this:

{
    "id": "5ea2aa99-4020-4d9f-9d1f-1737d5df2a6e",
    "amount": 15.0
}

The amount was fine, but the ID kept returning null. Why?

Jackson and Java Reflection: The Silent Saboteurs

Spring Boot uses Jackson for JSON serialization and deserialization. But here’s something most people don’t realize:

Jackson doesn’t look at field names. It looks at method names—specifically getters.

This is where Java reflection comes in. Jackson scans your class for getter methods (methods that start with get), removes the get prefix, and converts the first letter to lowercase.

And that’s exactly where my problem was hiding.

The Naming Mismatch That Broke Everything

Let's look at the Payment class in Service A (Client):

public class Payment {
    private String id;
    private double amount;

    public String getRequestId() {  // This is the problem!
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

    // Getters/Setters for amount...
}

Wait… What’s Wrong Here?

My field name is id, but my getter method is getRequestId().
Jackson assumes the JSON key should be "requestId", not "id".
But my receiving service (Service B) expects the key to be "id", not "requestId".

Meanwhile, in Service B (Server), the class looks like this:

public class Payment {
    private String id;
    private double amount;

    public void setId(String id) {
        this.id = id;
    }
}

So Service B was looking for "id" in the JSON… but it wasn’t there. Instead, the JSON had "requestId", which Service B didn’t recognize, causing id to be null.

Boom. Naming mismatch = Bug.

The Fix: How to Prevent This Issue

Solution 1: Use Consistent Getter and Setter Names (Best Practice)

The cleanest fix is to follow JavaBean conventions properly:

public String getId() {
    return id;
}

public void setId(String id) {
    this.id = id;
}

Now, Jackson will correctly map the id field in JSON.

Solution 2: Use `@JsonProperty` for Explicit Mapping (When You Can’t Rename)

If renaming isn’t an option (e.g., for backward compatibility), use @JsonProperty:

import com.fasterxml.jackson.annotation.JsonProperty;

@JsonProperty("id")  // Force JSON to use "id" instead of "requestId"
public String getRequestId() {
    return id;
}

This tells Jackson:

"I don’t care what the method name is—just use 'id' as the field name in JSON."

Testing Your Fix (Trust, but Verify)

After fixing the issue, I wrote a quick test to ensure it worked:

@Test
public void testJsonSerialization() throws Exception {
    Payment payment = new Payment();
    payment.setId("test-id");
    payment.setAmount(15.0);

    ObjectMapper mapper = new ObjectMapper();
    String json = mapper.writeValueAsString(payment);

    assertTrue(json.contains("\"id\":\"test-id\""));
}

This simple test saved me hours of potential headaches later.

Key Takeaways (Lessons Learned)

Follow JavaBean Conventions – Name your getters and setters exactly like your fields.
Jackson Maps Methods, Not Fields – It uses getters, not variable names, for JSON property names.
Use @JsonProperty When Necessary – If you can’t rename, force Jackson to use the correct key.
Test Your Serialization – Always verify how your objects get converted to JSON.

Conclusion: One Tiny Naming Mistake, One Giant Bug

Sometimes, the most frustrating bugs come from the simplest mistakes. In my case, a getter name mismatch silently broke JSON mapping between two services.

Moral of the story? Naming your getters and setters correctly is like giving your code a GPS—it actually knows where to find things.

So next time you see unexpected null values when exchanging JSON between services, take a close look at your getter and setter method names.

The answer might be staring you right in the face.

Paladin: a job application manager

Oluwatimilehin Awoniyi — Tue, 27 Feb 2024 12:37:55 +0000

Paladin helps job seekers manage their job applications and easily apply to vacancies that provide email addresses to where applications are to be made. Our team members are Ayomide ADETULE and myself. Our focus and interest were essentially in the frontend part of engineering, hence, we chose to utilise Supabase for the backend.

The story behind Paladin mirrors the current reality of job searching, the wide array of skills that individuals possess and the need to have an interface/profile for these skills, all for the purpose of making the process of job applications easier and unified. For me, this will mean I can create an interface as a frontend engineer, brand identity designer and technical writer all under a profile and manage them accordingly!

For the frontend, we chose to use Sveltekit, a JavaScript framework. We opted for this because it is one of the closest things to writing HTML5, CSS3 and JavaScript! We didn’t want to delve into the nuance and intricacies of a more technical framework like React. For the backend, we chose Supabase to handle the backend for us!

We have achieved responsiveness of the web app, setup and integration with Supabase and we have set up a PostgreSQL database with the help of Supabase. We were going to simply authenticate users via email and passwords till we got notice of magic links, hence, we are currently migrating to adopting this feature!

One of the most technical challenges I faced in this project was integrating SwiperJS to work with Sveltekit! This was not an issue of knowledge but that of conflicting documentation on the SwiperJS website. They were migrating to a version and recommended an approach to installing and using their features, but the recommended mode of installation was not compatible with the content of the documentation. The task was then to find a way to install, implement and successfully use the particular carousel feature we wanted. I went to the GitHub code of SwiperJS to understand the code and I also checked out some of the implementations of previous users on code sandboxes online but those didn’t help. In reading and studying the code on GitHub and going over the documentation, I was able to create a synergy and I crafted a way to add the feature! The result is currently the first feature in the feature section of our landing page: the carousel!

This project taught me that beyond writing codes, understanding what is needed to be done is prior, hence, finishing the problem on paper before writing code is an important aspect of engineering. Going forward, I’ll always have a blueprint of my intended solution on paper before getting to code!

Github link for the project

Link to deployed page

How To Troubleshoot a Silent Webpage (A Docker Misadventure)

Oluwatimilehin Awoniyi — Mon, 15 Jan 2024 10:35:56 +0000

Introduction:

Ever faced a webpage that refuses to say a word? Join me in unraveling a recent hiccup in our Docker adventures, where an innocuous port-curling expedition turned into an unexpected outage. In this blog post, we'll navigate through the timelines, actions taken, and the crucial lessons learned from this episode.

The Incident: A Webpage Goes Mute

It all started on a regular Monday morning at 10:47 AM (WAT). Eager to check on the latest Docker container, I initiated a simple curl command on port 8080 mapped to the container's port 80. To my surprise, instead of a cheerful page, I was greeted with the ominous message: "empty reply from server."

The Impact: Silent Users and Empty Pages

The repercussions were swift. Our webpage turned into a mute spectator, rendering nothing but an empty response. Quick estimates suggested about 5% of our users were caught in this silent storm.

Root Cause: The Vanishing Server Start

The detective work began. The culprit? A server that mysteriously forgot to start after a recent operation. A simple oversight, yet one that sent ripples through our digital landscape.

Timeline: The Race Against Time

At 10:47 AM, the silent alarm was raised, not by a user complaint, but by our vigilant monitoring alert. The race against time had begun.

Actions Taken: Unveiling the Silent Server

The first move was to inspect the server's whereabouts. What port was it listening to? Was it even awake? A thorough check revealed the dormant state of our crucial server.

Resolution: Reviving the Silent Server

With the issue laid bare, the solution was straightforward: start the server! However, to prevent such muteness in the future, a Puppet script was introduced. Now, every server update triggers an automatic start, silencing any potential disruptions.

Initially using a bash script, this was used:

#!/usr/bin/env bash
# get Apache to run on the container and to return a page

service apache2 start

With Puppet for automation, let's create a Puppet manifest file. Let's call it apache_service.pp:

# File: apache_service.pp

# Define a class for managing the Apache service
class apache_service {
  service { 'apache2':
    ensure => 'running',
    enable => true,
    subscribe => File['/etc/apache2/httpd.conf'], # Trigger the service restart when the Apache configuration file is updated
  }
}

# Apply the class to ensure it is included when Puppet runs
include apache_service

Root Cause and Resolution: Learning from the Silence

The root cause was a temporarily faulty server, fixed but left in silence. The resolution? A proactive decision to script server starts, ensuring they speak up after every update.

Corrective and Preventative Measures: Scripts and Vigilance

To fortify our defenses, every engineer is now armed with mandatory pre and post-server operation scripts. Additionally, the Quality Assurance team is on high alert, (re)educated on the nuances of our vigilant monitoring tools.

Conclusion: Lessons from Silence

In the ever-evolving landscape of Docker and servers, even a momentary silence can be deafening. This incident taught us the importance of vigilance, automation, and proactive measures. Let this be a reminder to all: in the realm of webpages, silence is not always golden.