3

(免責事項: 極端に単純化しています。実際のシナリオはかなり複雑です。)

Producer と Consumer の 2 つのシステムがあるとします。それらのコードは、単一の共有インターフェースを除けば、完全に独立しています。

public interface Thing {
    String getName();
    String getDescription();
    int getPrice();
}

Producer が一連のデータを作成し、HTTP 経由で JSON として送信するという考え方です。Producer には一連の Thing の実装があり、それぞれに追加のメタデータとデータ生成プロセスで必要なものがあります。

最上部の薄いレイヤーを除いて、プロデューサーがジャクソン/シリアライゼーションに関する何らかの知識を持つことは望ましくないため、シリアライゼーション属性はモノの実装から除外する必要があります。実装の量は将来的に増加する可能性が非常に高いため、それらすべてに mixin を使用することはすぐに持続不可能になります。Thing インターフェース自体にアノテーションを適用するだけで十分であると考えられていました。

最初の単純なアプローチは、インターフェースの @JsonSerialize アノテーションでした。最初はうまくいくように見えましたが、問題が発生しました。Thing の実装の一部は列挙型であるため、Jackson はそれらをインターフェイスで定義されたフィールドではなく、名前として単純にシリアル化します。

いくつかのグーグルは、次の注釈を明らかにしました:

@JsonFormat(shape= JsonFormat.Shape.OBJECT)

名前の代わりにフィールドをシリアル化することで実際に問題を解決しましたが、Thing インターフェースで定義されていない実装固有のパブリック フィールドシリアル化し始めたため、情報漏えいだけでなく、逆シリアル化の失敗にもつながりました。不明なエントリを含むデータが原因で、コンシューマで。

さらにグーグルで調べても結果が得られなかったので、私が考えることができる唯一の解決策は、これらすべてのフィールドを無視できるものとしてマークすることです。これは、前述の理由により非常に望ましくありません。

インターフェイス自体とその注釈を変更するだけで、クラスと列挙型の両方でこれらのフィールドを厳密にシリアル化する必要があることを強制する方法はありますか?

4

2 に答える 2