Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

10 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, vendor, related_branches, related_projects, tags, status, confidence, created, last_reviewed

title

source_type

url

archive_url

vendor

related_branches

related_projects

Jakarta Bean Validation 3.0 Specification

Layer: raw/ — 외부 자료(공식 문서)의 원문 발췌·출처 기록. 원본은 Eclipse Foundation Specification License (v1.0) 하에 공개된 Jakarta EE 사양서. 검증된 요약은 /ingest 후 wiki/concepts/ 에 별도 작성. 원본은 raw 에 영구 보관.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-boundary-validation-mapping-contract	4-layer validation (syntax / policy / invariant / persistence integrity) 중 cross-field / class-level constraint 와 group sequence 의 책임 위치 정의 (블라인드 B4). Bean Validation 의 normative 위임 범위 + ca-tmpl 의 application/domain 으로의 group propagation 결정 근거
raw/branch-notes/feature-business-rule-validation-contract	(sibling branch) 동일 4-layer 분류에서 policy / invariant layer 의 Bean Validation 위임 가능 범위 판단 근거

출처 / Source

원본 URL: https://jakarta.ee/specifications/bean-validation/3.0/jakarta-bean-validation-spec-3.0.html
아카이브 URL: (미기재)
저자 / 조직: Eclipse Foundation, Jakarta EE (formerly JCP JSR-380)
발행일: 2020 (Jakarta Bean Validation 3.0, successor to JSR-380 / Bean Validation 2.0)
마지막 확인일: 2026-05-28

왜 저장했는지 / Why archived

feature-boundary-validation-mapping-contract branch 의 블라인드 스팟 B4: class-level constraint / @AssertTrue / group sequence 의 책임 위치(syntax vs invariant)가 회색지대로 남아 있음. Jakarta Bean Validation 3.0 spec의 normative 진술로 class-level constraint 의 목적, group sequence 의 short-circuit 의미론, @Valid cascade 깊이, 그리고 3.0 에서 추가된 container element (TYPE_USE) 위치를 확정하기 위해 저장.

핵심 인용 / Key quotes (verbatim, Self-Grep 통과)

[§5.1.1 Object validation] "Applying a constraint to a class or interface expresses a validation over the state of the class or the class implementing the interface."

[§5.2 Constraint declaration] "When a constraint is defined on a class, the class instance being validated is passed to the ConstraintValidator."

[§5.4.2 Group sequence] "Each group in a group sequence must be processed sequentially in the order defined by @GroupSequence.value when the group defined as a sequence is requested." [...] "if one of the groups processed in the sequence generates one or more constraint violations, the groups following in the sequence must not be processed."

[§5.1.3 Graph validation] "In addition to supporting instance validation, validation of graphs of objects is also supported. The result of a graph validation is returned as a unified set of constraint violations. @Valid is used to express validation traversal of an association."

[§3.1 Constraint annotation — Generic constraint target ElementTypes] "Generic constraint annotations can target any of the following ElementTypes: FIELD for constrained attributes / METHOD for constrained getters and constrained method return values / CONSTRUCTOR for constrained constructor return values / PARAMETER for constrained method and constructor parameters / TYPE for constrained beans / ANNOTATION_TYPE for constraints composing other constraints / TYPE_USE for container element constraints"

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
JBV-3.0-C1	class-level constraint 는 클래스 인스턴스 전체(여러 프로퍼티)의 상태를 검증하기 위한 수단이다	[§5.1.1] "Applying a constraint to a class or interface expresses a validation over the state of the class or the class implementing the interface."	`official-standard`	jakarta.validation 호환 구현체 전체	구체적으로 어떤 레이어(syntax/invariant)에 두어야 하는지는 사양이 명시하지 않음 — 배치 전략은 애플리케이션 설계 결정
JBV-3.0-C2	class-level constraint 가 실행되면 ConstraintValidator 에게 클래스 인스턴스 자체가 전달된다	[§5.2] "When a constraint is defined on a class, the class instance being validated is passed to the `ConstraintValidator`."	`official-standard`	class-level constraint validator 구현 시	ConstraintValidator 내부에서 다른 필드를 어떻게 접근할지(reflection vs getter)는 명시하지 않음
JBV-3.0-C3	group sequence 는 선언 순서대로 그룹을 순차 처리하며, 앞 그룹에서 violation 이 발생하면 이후 그룹은 실행하지 않는다 (short-circuit)	[§5.4.2] "Each group in a group sequence must be processed sequentially in the order defined by @GroupSequence.value when the group defined as a sequence is requested." + "if one of the groups processed in the sequence generates one or more constraint violations, the groups following in the sequence must not be processed."	`official-standard`	@GroupSequence 사용 시 어디서든 (application, domain)	그룹 시퀀스 자체가 "어느 아키텍처 레이어에서 어떤 groups 를 넘길지"를 결정하지 않음 — 호출 코드 결정
JBV-3.0-C4	@Valid 는 연관 객체 그래프에 재귀적으로 validation 을 전파하며 @Valid annotation 은 recursive 하게 적용된다	[§5.1.3] "In addition to supporting instance validation, validation of graphs of objects is also supported. The result of a graph validation is returned as a unified set of constraint violations. @Valid is used to express validation traversal of an association."	`official-standard`	모든 @Valid 사용 위치 (field, method parameter, return value, type argument)	@Valid 가 붙어 있어도 TraversableResolver.isCascadable() 가 false 를 반환하면 cascade 하지 않음 — JPA 통합 등에서 다름
JBV-3.0-C5	Jakarta Bean Validation 3.0 에서 generic constraint 는 FIELD / METHOD / CONSTRUCTOR / PARAMETER / TYPE / ANNOTATION_TYPE / TYPE_USE 7개 ElementType 을 타깃으로 선언 가능하다 (TYPE_USE 는 container element constraint 용)	[§3.1] "Generic constraint annotations can target any of the following ElementTypes: FIELD for constrained attributes / METHOD for constrained getters and constrained method return values / CONSTRUCTOR for constrained constructor return values / PARAMETER for constrained method and constructor parameters / TYPE for constrained beans / ANNOTATION_TYPE for constraints composing other constraints / TYPE_USE for container element constraints"	`official-standard`	Jakarta Bean Validation 3.0 호환 구현체 (Hibernate Validator 7+)	TYPE_USE 는 Bean Validation 2.0(JSR-380) 에서 추가됨. 3.0 은 Jakarta namespace 이동이 주된 변경 — 새 constraint 타깃 추가 아님

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- JBV-3.0-C1, JBV-3.0-C2: class-level constraint 는 여러 필드를 동시에 검증하는 normative 수단임. Bean Validation 사양의 공식 설계 의도.
- JBV-3.0-C3: group sequence 의 short-circuit 은 spe 이 의무화(MUST)한 동작. 구현체 의존 아님.
- JBV-3.0-C4: @Valid 는 재귀적으로 적용됨 — cascade 깊이 제한 없음. 단 무한루프 방지 로직(동일 navigation path 내 동일 인스턴스 중복 skip)이 사양에 명시됨.
- JBV-3.0-C5: 7가지 declaration location 전체가 3.0 spec 의 표준 범위 내.
이 자료가 증명하지 않는 것:
- class-level constraint 를 syntax 레이어에 둘지 invariant 레이어에 둘지 — 사양은 아키텍처 레이어를 정의하지 않음.
- application service 가 groups 를 인자로 받아 Bean Validation 을 위임해야 한다는 것 — 호출 전략은 사양 범위 밖.
- @AssertTrue 가 invariant 인지 syntax 인지 — @AssertTrue 는 단순 boolean 검사용 constraint 이며 사양은 의미적 분류를 강제하지 않음.
- group propagation 정책 (application layer 가 domain 에 어떤 groups 를 전달할지) — 사양 외 설계 결정.
내 프로젝트(ca-skeleton/ca-tmpl) 에 적용하려면 추가 확인이 필요한 것:
- Spring Validation (@Validated) 과 Jakarta Bean Validation 의 groups 연동 방식 — Spring AOP 인터셉터가 groups 를 어떻게 위임하는지 Spring 공식 문서 별도 확인.
- Hibernate Validator 7.x 의 Jakarta namespace 전환 호환성 — ca-tmpl 이 사용하는 Spring Boot 3.x 의 기본 BV provider 버전 확인.

메모 / Notes

class-level constraint (TYPE ElementType) 와 cross-parameter constraint (PARAMETER array, @SupportedValidationTarget(PARAMETERS)) 는 별개 개념. 전자는 클래스 인스턴스 전체, 후자는 메서드/생성자의 복수 파라미터를 검증.
@GroupSequence 를 클래스 위에 직접 붙이면 해당 클래스의 Default 그룹을 재정의(override)하는 효과. 이를 이용해 syntax → policy → invariant 순 staged validation 구현 가능하지만 사양은 이 패턴을 권장 사례로 명시하지 않음.
사양 §5.7.1 은 @Valid 의 무한루프 방지 규칙(같은 navigation path 에서 같은 인스턴스 재등장 시 skip)을 normative 로 정의 — 순환 참조 도메인 모델에서도 안전.
TYPE_USE 지원(container element)은 JSR-380(Bean Validation 2.0)에서 도입. Jakarta 3.0 은 주로 javax.validation → jakarta.validation namespace 이전이 핵심 변경사항.

같은 주제 Spring 공식 문서: raw/official-docs/spring-tx-management-reference (validation 과 tx 결합 패턴 참고)
Hibernate Validator (레퍼런스 구현) 문서: 미아카이브 — 필요 시 추가
이 자료를 인용한 wiki 요약: wiki/concepts/bean-validation-constraint-taxonomy (생성 시)

10 KiB Raw Permalink Blame History