Custom validator annotation in Spring Boot - Step-by-Step Execution

Concept Flow - Custom validator annotation

Define Annotation Interface

↓

Create Validator Class

↓

Implement isValid() Method

↓

Apply Annotation to Field

↓

Spring Boot Validation Trigger

↓

Validator Checks Field Value

↓

Validation Passes or Fails

↓

Return Result to Framework

This flow shows how a custom annotation is defined, linked to a validator class, applied to a field, and then used by Spring Boot to validate input.

Execution Sample

Spring Boot

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = MyValidator.class)
public @interface MyConstraint {
  String message() default "Invalid value";
  Class<?>[] groups() default {};
  Class<? extends Payload>[] payload() default {};
}

public class MyValidator implements ConstraintValidator<MyConstraint, String> {
  @Override
  public boolean isValid(String value, ConstraintValidatorContext context) {
    return value != null && value.matches("\\d+");
  }
}

Defines a custom annotation and validator that checks if a string contains only digits.

Execution Table

Step	Action	Input Value	Validation Check	Result
1	Annotation applied to field	"12345"	Check if value matches digits only	Valid
2	Annotation applied to field	"abc123"	Check if value matches digits only	Invalid
3	Annotation applied to field	null	Check if value is not null and digits only	Invalid
4	Validation completes	-	-	Validation result returned to framework

💡 Validation stops after checking input value and returning pass/fail result

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
value	undefined	"12345"	"abc123"	null	varies per input
isValid	undefined	true	false	false	true or false

Key Moments - 3 Insights

Why does the validator return false when the input is null?

Because the isValid method explicitly checks for null and returns false if the value is null, as shown in step 3 of the execution_table.

How does Spring Boot know to use the custom validator?

The custom annotation is linked to the validator class via @Constraint annotation on the annotation interface, so Spring Boot calls isValid automatically when validating the annotated field.

What happens if the input string contains letters and digits?

The validator returns false because the regex check fails, as shown in step 2 of the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the validation result when the input is "abc123"?

A Valid

B Invalid

C Null

D Not checked

💡 Hint

Check row 2 in the execution_table where input is "abc123" and result is shown

At which step does the validator return false because the input is null?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the execution_table row where input value is null

If the regex in isValid changed to allow letters, how would the result for input "abc123" change?

A It would remain Invalid

B It would cause an error

C It would become Valid

D It would be null

💡 Hint

Consider how the validation check result depends on the regex matching the input

Concept Snapshot

Define a custom annotation interface with @Constraint.
Create a validator class implementing ConstraintValidator.
Override isValid() to check the field value.
Apply annotation to fields to validate.
Spring Boot calls isValid during validation.
Returns true if valid, false if invalid.

Full Transcript

This visual execution shows how to create and use a custom validator annotation in Spring Boot. First, you define an annotation interface with @Constraint linking to a validator class. Then, you create a validator class implementing ConstraintValidator and override the isValid method to check the input value. When you apply the annotation to a field, Spring Boot automatically calls the validator during validation. The execution table traces different input values through the validator, showing when validation passes or fails. Key moments clarify why null inputs fail and how Spring Boot connects the annotation to the validator. The quiz tests understanding of validation results and behavior changes. This step-by-step trace helps beginners see how custom validation works in practice.

Practice

1. What is the main purpose of creating a custom validator annotation in Spring Boot?

easy

A. To define your own validation rules reusable across your application

B. To replace built-in annotations like @NotNull completely

C. To automatically generate database tables

D. To handle HTTP requests in controllers

Solution

1. Step 1: Understand the role of custom validator annotations

   They allow you to create your own rules for validating data beyond built-in checks.

2. Step 2: Identify the main benefit

   These annotations keep validation logic clean and reusable across different parts of your app.

3. Final Answer:

   To define your own validation rules reusable across your application -> Option A

4. Quick Check:

   Custom validator = reusable validation rules [OK]

Hint: Custom validators create reusable rules, not replace built-ins [OK]

Common Mistakes:

• Thinking custom validators replace all built-in annotations
• Confusing validation with database or HTTP handling
• Assuming custom validators auto-generate code

2. Which of the following is the correct way to declare a custom validator annotation interface in Spring Boot?

easy

A. @Validator class MyValidator { String message() default "Invalid"; }

B. class MyValidator { String message() default "Invalid"; }

C. interface MyValidator { void validate(); }

D. @interface MyValidator { String message() default "Invalid"; Class[] groups() default {}; Class[] payload() default {}; }

Solution

1. Step 1: Recall the syntax for custom annotation interfaces

   They use @interface keyword and define methods like message(), groups(), and payload().

2. Step 2: Check each option

   @interface MyValidator { String message() default "Invalid"; Class[] groups() default {}; Class[] payload() default {}; } correctly uses @interface and includes required methods. Others either use wrong keywords or miss required parts.

3. Final Answer:

   @interface MyValidator { String message() default "Invalid"; Class[] groups() default {}; Class[] payload() default {}; } -> Option D

4. Quick Check:

   Custom annotation = @interface + standard methods [OK]

Hint: Custom annotations use @interface with message, groups, payload [OK]

Common Mistakes:

• Using class or interface instead of @interface
• Omitting groups() or payload() methods
• Adding methods unrelated to validation

3. Given this validator class snippet, what will happen when validating a string with value "abc123"?

public class AlphaValidator implements ConstraintValidator<Alpha, String> {
  public boolean isValid(String value, ConstraintValidatorContext context) {
    return value != null && value.matches("^[a-zA-Z]+$");
  }
}

medium

A. Validation throws a NullPointerException

B. Validation passes because the string contains letters

C. Validation fails because the string contains digits

D. Validation always returns true regardless of input

Solution

1. Step 1: Analyze the validation logic

   The method checks if the string is not null and matches the regex "^[a-zA-Z]+$", which means only letters allowed.

2. Step 2: Test the input "abc123" against the regex

   Since "abc123" contains digits, it does not match the regex, so the method returns false.

3. Final Answer:

   Validation fails because the string contains digits -> Option C

4. Quick Check:

   Regex allows only letters, digits cause failure [OK]

Hint: Check regex carefully; digits break letter-only pattern [OK]

Common Mistakes:

• Assuming partial match passes validation
• Ignoring null check in code
• Thinking digits are allowed by regex

4. You wrote a custom validator but it always passes validation even for invalid data. Which of these is the most likely cause?

medium

A. The annotation interface is missing the @Target annotation

B. The isValid method always returns true regardless of input

C. The validator class does not implement ConstraintValidator

D. The message() method in the annotation returns an empty string

Solution

1. Step 1: Understand the role of isValid method

   This method contains the validation logic and must return true only for valid inputs.

2. Step 2: Identify why validation always passes

   If isValid always returns true, invalid data will pass unchecked.

3. Final Answer:

   The isValid method always returns true regardless of input -> Option B

4. Quick Check:

   isValid controls validation result; always true means always pass [OK]

Hint: Check isValid method return values first when validation fails [OK]

Common Mistakes:

• Forgetting to implement ConstraintValidator interface
• Missing @Target causes compile warnings but not always validation failure
• Empty message() affects error text, not validation logic

5. You want to create a custom validator annotation @StartsWith that checks if a string starts with a given prefix. Which combination of elements is required to implement this correctly?

hard

A. An annotation interface with a String prefix() method, a validator class implementing ConstraintValidator<StartsWith, String>, and overriding isValid to check the prefix

B. An annotation interface with int length(), a validator class implementing Validator, and overriding validate to check length

C. A class annotated with @Component that implements ConstraintValidator without an annotation interface

D. An annotation interface with String suffix(), a validator class implementing ConstraintValidator<EndsWith, String>, and overriding isValid to check suffix

Solution

1. Step 1: Define the annotation interface with a prefix parameter

   The annotation must declare a method String prefix() to accept the prefix value.

2. Step 2: Implement the validator class correctly

   The validator class must implement ConstraintValidator<StartsWith, String> and override isValid to check if the string starts with the given prefix.

3. Final Answer:

   An annotation interface with a String prefix() method, a validator class implementing ConstraintValidator<StartsWith, String>, and overriding isValid to check the prefix -> Option A

4. Quick Check:

   Annotation + validator class + isValid checking prefix = correct [OK]

Hint: Match annotation method and validator generic types carefully [OK]

Common Mistakes:

• Using wrong method names like suffix() for prefix check
• Implementing wrong interfaces or missing annotation interface
• Confusing validate() with isValid() method names