Deprecate io.avaje.http.api.Valid in favor of the Avaje validation or Jakarta validation one?

Question

Deprecate io.avaje.http.api.Valid in favor of the Avaje validation or Jakarta validation one?

rbygrave opened this issue a year ago · 4 comments

I am wondering if it could be more confusing to have io.avaje.http.api.Valid when it is duplicating the Jakarta or Avaje Validation one (especially given that we don't need it with the cool way that prisms helps with this).

For myself, I am leaning towards deprecating and removing it.

Answer 1 · 2023-07-25T20:26:11.000Z

How would groups be set without it? I can imagine a case where some endpoints use the same beanparam but want different validations.

Answer 2 · 2023-07-25T20:29:37.000Z

That reminds me, I need to update the docs to really show this

Answer 3 · 2023-07-26T00:01:27.000Z

How would groups be set without it?

Right - in the case of jakarta validation, @Valid does not have a groups attribute. So in this case we need to use the avaje-http @Valid(groups=...)

So yeah, I think that means we do need to keep avaje-http @Valid.

I think there is maybe a followup question of, should groups attribute be added to io.avaje.validation.constraints.Valid ?

I think we close this one though, we need avaje-http @Valid to specify groups when using Jakarta Validation (and any other validation implementations).

Answer 4 · 2023-07-26T00:32:16.000Z

I think there is maybe a followup question of, should groups attribute be added to io.avaje.validation.constraints.Valid ?

Nah, it's only useful for HTTP, so it's just confusing to have it there when it has no use.