So far I have no luck with this.
- When I attempt quick fix with touching ConstraintValidator during startup to be initialized on working path it works, but ONLY for that specific validator. So in order for this to work I’d need to correctly know all available validators across whole module tree discoverable via ServiceLoader, make fake class to init them all, and hope everyone who will potentially adds new validator in future anywhere will know about this, and will also update my workaround. Maybe for me and my <20 validators and theoretically full control over everything it’s doable, but generally not viable soluion.
2. Then I tried to used programmatic validators definition(validators on fields/properties instead of xml declaration) while still using service loader to declare custom ConstraintValidator. Won’t work (new to programmatic approach) as ServiceLoader declaration does not apply for programmatic ConstraintValidator definition. So this is also dead end. 3. Then I tried both programmatic validators definition(instead of xml) and programmatic validators declaration. And this one does not work either. Since we do have the validators implemented in library which already uses ServiceLoader, which is used by several apps. So again, maybe it’s somehow doable, but generally no, we cannot make the ServiceLoader file go away, it is used already in public library, I cannot easily replace it. So what I did here, that I read ServiceLoader file myself and fed it into programmatic declaration of pairing, to make sure it’s there when needed. Which is this beauty:
which will produce this error on startup: Caused by: javax.validation.ValidationException: HV000193: mwe.validatorfail.validation.AnyUuid is configured more than once via the programmatic constraint definition API. Which is kinda funny. This code registers AnyUuid ONLY ONCE. So if this code does not run, validator for AnyUuid does not exist, if it does run it creates duplicity. Which means, that HibernateValidator after initialization is in ambivalent state, where it does have and does not have validator declared at the same time. So unless I’m doing something wrong, this is not a viable workaround either, since ServiceLoader and manual registration of validators cannot coexist. For me it might be doable, since I theoretically have full control over all apps using given library and can rewrite everything to avoid wrong parts of HibernateValidator, but generally it’s not viable workaround. Is there a another way, how we can keep ServiceLoader in place (we might not be able to rewrite public libraries depending on it) and somehow add non-annotation-based validations, which will work with validators defined in ServiceLoader? What is motivation behind it: we want to use annotation where possible, but some sources, like generated stubs, does not allow us (without nasty tricks which even might not be available everytime) to add annotation. |