Skip to content

Add toBuilder() default method to Problem interface#557

Open
Vinu2111 wants to merge 1 commit into
zalando:mainfrom
Vinu2111:feature/problem-to-builder
Open

Add toBuilder() default method to Problem interface#557
Vinu2111 wants to merge 1 commit into
zalando:mainfrom
Vinu2111:feature/problem-to-builder

Conversation

@Vinu2111
Copy link
Copy Markdown

Closes #507

What this does

Adds a toBuilder() default method to the Problem interface that creates a ProblemBuilder pre-populated with all standard fields from the current problem instance (type, title, status, detail, instance) plus any custom parameters from getParameters().

Motivation

A common use case is intercepting framework-built Problem responses to enrich them with cross-cutting parameters like trace IDs. Previously this required rebuilding the problem from scratch using Problem.builder(), which lost the original fields. With toBuilder() this becomes straightforward:

Problem enriched = problem.toBuilder()
    .with("traceId", traceId)
    .build();

Limitation

Type-specific fields from subclasses that are not exposed via getParameters() (e.g. violations on ConstraintViolationProblem) are not carried over, as this is an inherent constraint of the current architecture. This is documented in the method Javadoc.

Test coverage

5 test cases covering: full field copy, parameter copy, adding new parameters, overriding fields, and empty problem round-trip.

Adds a toBuilder() default method to the Problem interface that creates
a ProblemBuilder pre-populated with all standard fields from the current
problem instance (type, title, status, detail, instance) plus any custom
parameters from getParameters().

This enables a common use case where applications need to intercept and
enrich framework-built Problem responses with cross-cutting parameters
such as trace IDs, without losing the original problem fields:

    Problem enriched = problem.toBuilder()
        .with("traceId", traceId)
        .build();

Note: type-specific fields from subclasses that are not exposed via
getParameters() (e.g. violations on ConstraintViolationProblem) are
not carried over, as this is an inherent constraint of the current
architecture.

Closes zalando#507
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a 'toBuilder' method, for enhancing defaulted Problems

1 participant