9

私のプロジェクトの 1 つで、すでに Jersey をバージョン2.14から にアップグレードしました2.23。しかし、私は1つの問題で何時間も苦労しています。私のプロジェクトでは独自ExceptionMapperの a を定義しValidationExceptionていますが、残念ながら、Jersey にはこの例外用の組み込みの例外マッパーが既にあり、それをオーバーライドすることはできません。

以下に示す独自のマッパーを正しく登録しました（チェックしました）：

@Provider
public class ValidationExceptionMapper implements 
         ExceptionMapper<ValidationException> {

    @Override
    public Response toResponse(ValidationException exception) {
        return Response.status(Status.BAD_REQUEST).build();
    }
}

しかし、それは決して呼び出されていません。ジャージーは常にorg.glassfish.jersey.server.validation.internal.ValidationExceptionMapper. カスタムマッパーにも注釈を使用しようとしまし @Priorityたが、残念ながらJerseyはそれを考慮していません.

それで、何が起こっているのですか？以前のジャージー バージョンでは問題なく動作していたので、回帰バグのようです。

あきらめる。手がかりはありますか？

4

4 に答える 4

6

これは本当に、2015 年 1 月に導入された Jersey の回帰バグであることが判明しました。

バグは、Jersey の 2 つの拡張機能 (Weld と bean の検証用) に関連しています。Weld コンテナーが開始されていないため、カスタムValidationExceptionMapperマッパーがモジュールによって提供される組み込みのマッパーよりも優先されるjersey-bean-validationため、私の目標は達成されます。

JERSEY-3153の下にバグレポートを記入しましたが、後でissue #3425として移動しました。

正直なところ、ウェルド + ジャージーを二度と使用することはありません... この組み合わせにはうんざりです。過去 2 年間で、すでに約 10 個のバグに遭遇しました。本当に疲れた。

とにかく、それが誰かを助けることを願っています。

更新: 以下のコメントで @Justin Jose が気づいたように、言及されたバグには別の回避策もあります。HK2 バインディングを使用して、問題のある組み込みマッパーをオーバーライドできます。

register(new AbstractBinder() {
    @Override
    protected void configure() {
        bind(my.custom.ValidationExceptionMapper.class).to(ExceptionMapper.class)
               .in(Singleton.class);
    }
});
于 2016-08-11T13:59:42.587 に答える