Anyone familiar with validation using JSR-303 anno...

# announcements

[Jukka Siivonen]

Anyone familiar with validation using JSR-303 annotations ? I'm not sure if this is Kotlin related but I'm having difficulties defining my annotations using interface EDIT: Workaround is to use @JvmDefault on interface method

[Jukka Siivonen]

For example if I have interface

[Jukka Siivonen]

interface Foo {
    @AssertTrue
    fun isValid() = true
}

[Jukka Siivonen]

And bean

[Jukka Siivonen]

class FooBean: Foo

[Jukka Siivonen]

now validator.validate(FooBean()) causes two calls to isValid() function and I'm not sure why this is happening

[fred.deschenes]

which validation library are you using and how are you creating the validator instance?

[Jukka Siivonen]

Spring injected Validator -bean but I can try using Validation.buildDefaultValidatorFactory().validator directly too which I think is still used under hood for Spring Validator

[Jukka Siivonen]

does not seem to make a difference, both using Hibernate ValidatorImpl under the hood

[fred.deschenes]

mmm ok

[Jukka Siivonen]

Debugging implementation leads me to two MetaConstraint-instances

[Jukka Siivonen]

both have propertyName=valid

[Jukka Siivonen]

other has declaringClass=Foo

[Jukka Siivonen]

and the other one declaringClass=FooBean

[Jukka Siivonen]

so why the metadata model has both

[fred.deschenes]

you could try asking in #C0B8ZTWE4 if anyone's had that issue, I've used Hibernate Validator a bunch but in Dropwizard and don't recall ever having this happen

[rodolpho.couto]

@Jukka Siivonen there is an alternative to Bean Validation: https://github.com/valiktor/valiktor. With Valiktor, you can write your validations using a DSL instead of annotations 🙂

[Jukka Siivonen]

Thanks for suggestion, I submitted this question in Hibernate Validator forums https://discourse.hibernate.org/t/interface-validation-is-ran-twice-kotlin/2584

[Jukka Siivonen]

I have included decompiled Kotlin code in post above, maybe it can give some hints...

[Jukka Siivonen]

Using @JvmDefault on interface method seems to fix this issue

[Jukka Siivonen]

sounds like an ugly workaround 😞