1

Dropwizard サービスで、BadRequestException を拡張する新しい例外クラスを作成しました。

public class CustomBadRequestException extends BadRequestException {

    private static final long serialVersionUID = 1L;

    private List<ValidationFailureDto> validationFailures;

    public CustomBadRequestException() {
        super();
    }

    public CustomBadRequestException(final List<ValidationFailureDto> validationFailures) {
        super();
        this.validationFailures = validationFailures;
    }

    @ApiModelProperty(value = "List of validationFailures")
    public List<ValidationFailureDto> getValidationFailures() {
        return validationFailures;
    }
}

最初にその例外をスローしたとき、デシリアライズされた BadRequestException から追加のプロパティ (validationFailures) を引いたものしか返されませんでした。

{
code: "400",
message: "Bad request"
}

これは、Dropwizard の内部に、Jetty/Jackson がドメイン例外と適切な HTTP 応答の送信方法を理解できるようにするデフォルトの例外マッパーがあるためです。

これを克服するには、独自の ExceptionMapper クラスを実装し、Dropwizard に登録します。

public class CustomBadRequestExceptionMapper implements ExceptionMapper<SamplePackOrderBadRequestException> {

/**
 * Allows jackson to deserialise custom exceptions and its properties to JSON response
 *
 * @param exception exception
 * @return response object
 */
@Override
public Response toResponse(final SamplePackOrderBadRequestException exception) {

    if (exception instanceof SamplePackOrderBadRequestException) {

        SamplePackOrderBadRequestException samplePackOrderBadRequestException
                = (SamplePackOrderBadRequestException) exception;
        return Response
                .status(400)
                .entity(samplePackOrderBadRequestException)
                .build();
    }
    return Response.status(400).build();
}
}

ただし、これに関するこの問題は、スーパー (Throwable) を逆シリアル化するため、継承されたすべてのプロパティが応答に追加されますが、これは望ましくありません。

これに対抗するために、次のように Jackson アノテーションを追加してみました。

@JsonIgnoreProperties(value = "stackTrace")

stackTrace 以外に無視する必要のあるプロパティがいくつかあるため、これは最適なソリューションではありません。

要約すると、Dropwizard で CustomException クラスを適切に逆シリアル化するには、必要のない余分な混乱を招くことがないようにするにはどうすればよいでしょうか?

4

1 に答える 1