Adds a default validation exception handler

[SentryMan]

Resolves #669 by adding a default handler via the inject plugin

[SentryMan]

@mechite how's this?

[mechite]

@SentryMan hard to review on a phone 🤣 I like it

[mechite]

@SentryMan I'm reviewing here now on a computer.

1. RFC 9457 says that we should use application/problem+json or application/problem+xml` MIME types when using these standard error responses

2. It also states:

   The type URI is allowed to be a non-resolvable URI

   therefore, we actually don't need to point to the Avaje website.

We can do something like: tag:io.avaje.validator.constraints.Size#min, using the tag: URI scheme (not 100% sure how it's meant to be used).
But we can also just find a fluent way of excluding the "avaje" name from the response.

@SentryMan I see JSON Schema for HTTP Problems which is a specification for how the responses are meant to look.
Unfortunately, this schema is not published anywhere (for example the parent JSON Schema is published here].

While the following doesn't exclude the "avaje" name from the response, it does make it more abstract:

If we upload this schema to avaje.io/rfc9457.json, and put that into the response "type":, we get something that "has nothing to do with" / "is abstract to" the use of avaje, but is just a JSON description of what the response is meant to look like.

[SentryMan]

We can do something like: tag:io.avaje.validator.constraints.Size#min, using the tag: URI scheme (not 100% sure how it's meant to be used).

idk what to make of this statement

[mechite]

"your data failed the vibe check"

this guy

idk what to make of this statement

I mean that we basically can just point to a class file in Avaje, instead of a web URL

Ideally to me, this JSON schema I said that the RFC contains, could have been uploaded to e.g. ietf.org,
so our APIs written using avaje aren't now announcing to everyone who sends a bad request that
we are using avaje...
It's not a big deal or issue at all.

If we upload this schema to avaje.io/rfc9457.json

This suggestion was to say that we upload the official JSON schema, which is probably more useful
than pointing to the documentation of validator

[mechite]

d55a7a6 - OK, but we better verify that this is indeed valid for the tag: URI

[mechite]

a9d93ff

// Custom serialize so we don't need any json lib

Would this really be worth it over adding json-core or even full jsonb - since they have streaming writers?
Those libraries are so small and most people would have them anyway

[SentryMan]

Would this really be worth it over adding json-core or even full jsonb - since they have streaming writers? Those libraries are so small and most people would have them anyway

nahhh it's probably fine

[mechite]

🤣 he says it's fine, then optimizes anyway

[rbygrave]

I'm not convinced by the "packaging" of where this should be yet - for example the Helidon implementation probably should go into avaje-nima as that is the opinionated combination of validator + inject + helidon + jsonb.

This has to rely on optional dependencies and reflection which makes me go "Hmmm".

[SentryMan]

it's no worse than the automatic validator registration for http

[mechite]

BTW, just another note.
I know it's ugly but I've seen this done, and done this, a lot:

try {
    // access an optional dep
} catch (NoClassDefFoundError error) {
    // ignore
}

This works perfectly fine at runtime and avoids reflection API, and at the
bytecode level is a very simple check

[SentryMan]

you know I forgot you could catch those, time to replace every Class.forName

[SentryMan]

Helidon implementation probably should go into avaje-nima as that is the opinionated combination

What of the people that want to use hibernate or a custom implementation? This PR is supposed to be agnostic and not favor any specific validator implementation.

This has to rely on optional dependencies and reflection which makes me go "Hmmm".

Reflection is gone now, and we even have an optimized path through JPMS lookup when running on the module path. What downsides do you see of optional dependencies?