Skip to content

Add a test for a custom service-loaded constraint#53503

Draft
marko-bekhta wants to merge 2 commits intoquarkusio:mainfrom
marko-bekhta:test/add-a-test-for-serviceloaded-constraint
Draft

Add a test for a custom service-loaded constraint#53503
marko-bekhta wants to merge 2 commits intoquarkusio:mainfrom
marko-bekhta:test/add-a-test-for-serviceloaded-constraint

Conversation

@marko-bekhta
Copy link
Copy Markdown
Member

I was looking at the skills PR and noticed that we are not mentioning the service loader option to create new constraints even though that's the approach we were leaning towards in HV for a while..

Sooo this PR adds a test and I was wondering if we should add it to the guide as well ? 🙈

@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 8, 2026

🎊 PR Preview addf494 has been successfully built and deployed to https://quarkus-pr-main-53503-preview.surge.sh/version/main/guides/

  • Images of blog posts older than 3 months are not available.
  • Newsletters older than 3 months are not available.

@gsmet
Copy link
Copy Markdown
Member

gsmet commented Apr 8, 2026

@marko-bekhta in our guides, we should document the approach we are pushing forward. We don't need all options.

@marko-bekhta
Copy link
Copy Markdown
Member Author

@marko-bekhta in our guides, we should document the approach we are pushing forward. We don't need all options.

thanks, that makes sense 🙂 👍🏻
right now, we have an example with CDI (https://quarkus.io/guides/validation#constraint-validators-as-beans) which is good since it is about Quarkus specifics, but since we don't have anything else there about constraint validators, is CDI the way we want users to do it in Quarkus ?

Asking mostly since I've always thought we want users to go with service loader approach, and that was also my suggestion in this PR 🙈 :

https://github.com/quarkusio/quarkus/pull/53196/changes#diff-5e53738dadfbae76c59195597d1b355d1895e8cd5b65b1974c45198e4e869a6bR13-R19

@gsmet
Copy link
Copy Markdown
Member

gsmet commented Apr 9, 2026

Frankly, the skill looks quite confusing to me.

  • For simple constraints that are only applicable to the current type consider creating a simple boolean getter constrained with @AssertTrue: @AssertTrue(message="{message.key.for.this.check}") public boolean is[NameOfTheCheck]() { ... }

This is quite odd.

  • Test validation by sending invalid input via REST Assured and asserting 400 status.

This is also confusing as you will get 400 for very specific things such as annotating REST parameters with constraints.

I personally don't have time to review but if the skill looks inadequate and adds confusion, it's probably better to drop it than to confuse Claude (and spend tokens doing it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants