Handling JSONP Cross‑Origin Requests in Spring Boot: Common Pitfalls and Solutions

Hello everyone, I'm Afan. Recently I worked on a front‑back separated project and ran into a tricky backend issue while integrating the UEditor rich‑text plugin, which needs configuration data from the server.

Requirement

The frontend uses the Ueditor plugin, which expects the backend to provide a config JSON during initialization.

Initial Code

@RequestMapping(value = "/getConfig")
public Object getConfig(HttpServletRequest request) {
    return readConfig();
}

/**
 * Read configuration file
 */
private UedConfig readConfig() {
    String path = this.getClass().getResource("/").getPath();
    FileInputStream fileInputStream = new FileInputStream(path + "config/ued_config.json");
    // read and convert to object
    ...
}

After starting the service, the frontend reported that it could not obtain the configuration. Postman tests returned data correctly, but the browser showed a CORS error. The frontend claimed the request was JSONP, which I had never encountered before.

First Attempt at JSONP Support

Following a quick search, I added a simple Spring‑Boot controller advice for JSONP:

@ControllerAdvice
public class JsonpAdvice extends AbstractJsonpResponseBodyAdvice {
    public JsonpAdvice() {
        super("callback");
    }
}

Unfortunately, the class AbstractJsonpResponseBodyAdvice does not exist in Spring Boot 2.0 and later, so the code failed to compile.

Using Jackson's JSONPObject

Jackson provides JSONPObject , which can wrap a response for JSONP. I changed the endpoint to:

@RequestMapping(value = "/getConfig")
public Object getConfig(String callback, HttpServletRequest request) {
    return new JSONPObject(callback, readConfig());
}

After restarting, the endpoint worked in the development environment.

Deployment Issues

When the code was deployed to the test environment, the configuration could not be retrieved. The cause was a different CORS setting in the test environment, but after fixing that, another bug appeared: the path obtained by this.getClass().getResource("/").getPath() was incorrect because the application runs from a JAR packaged with an embedded Tomcat.

Correct Way to Load Resources from a JAR

I switched to loading the configuration file via an input stream:

/**
 * Read configuration file
 */
private UedConfig readConfig() {
    InputStream resourceAsStream = this.getClass().getResourceAsStream("/" + "config/ued_config.json");
    // read and convert to object
    ...
}

With this change the test environment worked correctly.

Summary

Key take‑aways:

Local development often runs on Windows, while test/production runs on Linux, leading to subtle differences.

Running from an IDE launches the application directly, whereas test and production run the packaged JAR, affecting resource loading.

Version differences (e.g., Spring Boot 2.x vs. older versions) can remove previously available utilities.

Always verify CORS settings and use proper JSONP handling when required.

Hope this share helps you avoid similar pitfalls. If you found it useful, please give it a like!