Bean Validation bug in Quarkus 3.0.0.Alpha2 but not in 3.0.0.Alpha1

[agoncal]

Describe the bug

There is a strange behaviour in Quarkus 3.0.0.Alpha2 when using Bean Validation ValidatorFactory and injecting Validator in the same test, which succeeds using 3.0.0.Alpha1.

I have a CD object with some constraints:

import jakarta.validation.constraints.*;

public class CD {

  @NotNull @Size(min = 4, max = 50)
  public String title;
  @NotNull @Positive
  public Float price;
  @Max(value = 5)
  public Integer numberOfCDs;

And I have two tests that succeed if run separately, but fail if run together.
The first test builds a ValidatorFactory to validate the CD object (and closes the factory at the end of the test).
And the second test injects a Validator to validate the CD object.
When run together, the second test fails (assertEquals(1, violations.size()); fails).

If both tests use the injected validator it succeeds.
If both tests use the ValidatorFactory it fails.

And no matter which combination of tests you use, the tests always succeed with 3.0.0.Alpha1.

@QuarkusTest
public class CDTest {

  @Inject
  Validator validator;

  @Test
  void shouldRaiseNoConstraintViolationWithDefault() {
    ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
    Validator validator = factory.getValidator();

    CD cd = new CD().title("Kind of Blue").price(12.5f);

    Set<ConstraintViolation<CD>> violations = validator.validate(cd);
    assertEquals(0, violations.size());

    factory.close();
  }

  @Test
  void shouldRaiseConstraintViolationValidatingNumberOfCDsProperty() {

    CD cd = new CD().numberOfCDs(7);

    Set<ConstraintViolation<CD>> violations = validator.validateProperty(cd, "numberOfCDs");

    assertEquals(1, violations.size());
    ConstraintViolation<CD> violation = violations.iterator().next();

    assertEquals("must be less than or equal to 5", violation.getMessage());
    assertEquals(7, violation.getInvalidValue());
    assertEquals("{jakarta.validation.constraints.Max.message}", violation.getMessageTemplate());
  }
}

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

I have created a reproducer : https://github.com/agoncal/agoncal-bug-quarkus-bv

Output of uname -a or ver

Darwin Antonios-MacBook-Air.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:15:52 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8112 arm64

Output of java -version

openjdk version "17.0.5" 2022-10-18 OpenJDK Runtime Environment Temurin-17.0.5+8 (build 17.0.5+8) OpenJDK 64-Bit Server VM Temurin-17.0.5+8 (build 17.0.5+8, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.0.0.Alpha2

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.6

Additional information

No response

[quarkus-bot]

/cc @gsmet(hibernate-validator), @yrodiere(hibernate-validator)

[gsmet]

It's not a bug, it's actually a feature.

Starting with 2.14, on which 3.0.0.Alpha2 is based, when trying to build a ValidatorFactory manually, we actually give you the Quarkus-managed ValidatorFactory.
Creating ValidatorFactory manually is not supported by Quarkus: typically it won't work in native executables thus why we did that as it gives a chance for frameworks creating a ValidatorFactory to actually work in Quarkus.
I forgot to mention it in the migration guide though, it needs an addition. Will do right away.

[agoncal]

@gsmet once you update the the migration guide, can you add the URL to this issue ? #Thanks

[gsmet]

I did it the other day. Here it is: https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.14#hibernate-validator .

That being said, I think we should prevent people from closing it as it is managed by Quarkus. I will go do that.

[gsmet]

I created #30039 to improve the situation.