私は、Java 8のtype_useアノテーションをサポートするHibernate Validator 5.2を使用しています。 Map内のListの内容を検証できるようにしたいとします。つまり、MapとListの内容がどのように入れ子になっていても、カスケードして検証するだけです。Hibernate Validator 5.2以降のマップでネストされたリストの検証
簡単な地図の例:私が好きな何
Map<String, List<Promotion>> promotionsByGroupName = ...;
は行うことができるようにすることです:
@Valid
Map<String, List<@Valid Promotion>> promotionsByGroupName = ...;
標準@Valid注釈を入れることができないとしてそれが動作しません。しかし、その要素に
@Valid
Map<String, List<@ValidPart Promotion>> promotionsByGroupName = ...;
しかし、@ValidPartに関連付けられたバリデータがトリガされることは決してありません。だから私は、私はそこに配置することが許可されていたカスタム注釈を作成しました。
@Valid
Map<String, @ValidPart List<Promotion>> promotionsByGroupName = ...;
...そしてアンラップリストを関連するバリデータで取得する要素を検証するために(どの残念ながら:
私は得ることができた最も近いが、このようなリストに@ValidPart注釈を入れていましたConstraintValidatorの内部でValidatorを呼び出し、結果のConstraintViolationsを「書き換える」)。
私の質問は、リストをトラバースせずにこれらの種類のネストされたバリデーションを行う方法がありますか?
promotionsByGroupName[GroupName].[0].name cannot be null
の代わりに(地図キー名とインデックスの間にはドット):彼らがどのように見えるとして、これは生成制約違反パスは、私が探しているかなり何ではありません
promotionsByGroupName[GroupName][0].name cannot be null
[現時点では
for (ConstraintViolation<?> violation : validator.validate(value)) {
NodeBuilderCustomizableContext builder = context
.buildConstraintViolationWithTemplate(violation.getMessage())
.addPropertyNode("[" + i + "]");
for (String nodeName : violation.getPropertyPath().toString().split("\\.")) {
builder = builder.addPropertyNode(nodeName);
}
builder.addConstraintViolation();
}
私は、失敗した元のConstraintDescriptorを新しい制約違反で保持することができないため、ConstraintValidator内でValidatorを呼び出すことは役に立たないという結論に達しました。 JSR-303仕様は単純な人やアドレスの違反には適しているようですが、複雑な実世界のデータ構造で使用すると厳しくはありません。私自身のローリング。 – john16384