Make `type` in `ProblemDetail` nullable by cw-dimedis · Pull Request #35294 · spring-projects/spring-framework

cw-dimedis · 2025-08-06T12:36:05Z

Make ProblemDetail type field nullable to improve JSON serialization

Background

According to RFC 9457 Section 3.1.1 the "type" member is optional and when not present, its value is assumed to be "about:blank". The current Spring implementation explicitly sets this default value, which results in all problem responses containing the unhelpful "type": "about:blank" field even when no specific problem type is needed.

Changes

This change makes the type field nullable in ProblemDetail:

Updated setType(@Nullable URI type) to accept null values
Updated getType() to return @Nullable URI
Removed the Assert.notNull() validation that prevented null types

Compatibility

This change is completely non-breaking. Existing users will not notice any difference in behavior:

The type field is still initialized to BLANK_TYPE ("about:blank") by default
Existing code that relies on the type always being present continues to work unchanged
JSON serialization will continue to show "type": "about:blank" for existing usage patterns

The only difference is that developers can now optionally set the type to null if they want cleaner JSON output without the default "about:blank" value.

Benefits

Optional cleaner JSON output: Developers can now choose to omit the type field entirely by setting it to null
RFC compliance: Aligns with the RFC 9457 specification where the type field is truly optional
Zero impact on existing code: All current usage patterns continue to work exactly as before

Example

For users who want cleaner output, they can now do:

ProblemDetail problem = ProblemDetail.forStatus(400);
problem.setType(null); // Now possible - results in cleaner JSON

This change provides more flexibility while maintaining complete backward compatibility.

Signed-off-by: Christoph Wagner <cwagner@dimedis.de> Signed-off-by: Christoph <cwagner@dimedis.de>

rstoyanchev

Thanks for the suggestion.

The @Nullable on the getter can cause issues for existing code. In 6.2.x we could avoid adding those and simply remove the Assert.notNull. It would put the burden on code setting a null value, but at least make it possible.

For 7.0 in the main branch we can accept the changes as is.

cw-dimedis · 2025-08-08T07:25:03Z

@rstoyanchev Thanks for the feedback and the pragmatic approach for 6.2.x vs 7.0!

For 7.0, I'd suggest we could go further and remove the default BLANK_TYPE initialization entirely. The field would be null by default, giving cleaner JSON output out of the box and full RFC 9457 compliance without requiring developers to explicitly set type to null.

Is that something the team would consider? Shall I add another commit to prepare that change?

Cheers, Christoph

rstoyanchev · 2025-08-08T07:32:20Z

That makes sense. Please, add the extra change.

Signed-off-by: Christoph Wagner <cwagner@dimedis.de>

See gh-35294

See gh-35294 Signed-off-by: Christoph Wagner <cwagner@dimedis.de> Signed-off-by: Christoph <cwagner@dimedis.de>

Spring Framework 7 removed the default "about:blank" value for the ProblemDetail type field (see spring-projects/spring-framework#35294). This change preserves the previous behavior by introducing CamundaProblemDetail with a wrap() method that ensures all error responses include the "about:blank" type value. Changes: - Add CamundaProblemDetail.wrap() method to copy properties from existing ProblemDetail while ensuring type defaults to "about:blank" - Update GlobalControllerExceptionHandler to wrap ProblemDetail instances returned by Spring's exception handlers - Update test classes to use CamundaProblemDetail for expected responses Link: spring-projects/spring-framework#35294

Add an ArchUnit test that ensures org.springframework.http.ProblemDetail is never instantiated directly in the codebase. Instead, io.camunda.gateway.protocol.model.CamundaProblemDetail should be used. Spring Framework 7 removed the default 'about:blank' value for the 'type' field in ProblemDetail (see spring-projects/spring-framework#35294). CamundaProblemDetail restores this default to ensure backward compatibility with API consumers expecting the RFC 9457 compliant 'about:blank' default value. The rule allows imports and type references to ProblemDetail (e.g., for method signatures or type checks) but forbids: - Constructor calls - Factory method calls (forStatus, forStatusAndDetail) The CamundaProblemDetail class itself is exempt as it extends ProblemDetail.