While trying to fix this issue I found out that if one depends on:
- org.glassfish.jersey.ext:jersey-spring3:2.12 and
- org.glassfish.jersey.ext:jersey-bean-validation:2.12
classpath will contain
- javax.validation:validation-api and
- org.hibernate:hibernate-validator as separate jar dependencies, but also
(transitively from hk2)
- OSGi-fied org.glassfish.hk2.external:bean-validator with validation-api
and hibernate-validator shaded in the bean-validator jar
Having validation-api and hibernate-validator as separate jars and shaded
in another jar is very unlikely to be wanted.
I'm solving this classpath issue by excluding bean-validator dependency
from hk2-config.
Kind regards,
Stevo Slavic.
On Thu, Sep 11, 2014 at 4:18 PM, Stevo Slavić <sslavic_at_gmail.com> wrote:
> Hello Jersey community,
>
> I wanted my error messages in validation error response to have
> appropriate parameter/field names. DefaultParameterNameProvider is really
> limited. It's not even attempting to read parameter names from debug
> information or use java 8 parameter name discovery when available.
>
> To implement and configure custom ParameterNameProvider I've followed 2.12
> docs example at
> https://jersey.java.net/documentation/2.12/bean-validation.html#bv.example.ValidationConfig
> and its more updated variant in jersey code on github
> https://github.com/jersey/jersey/blob/2.12/examples/bean-validation-webapp/src/main/java/org/glassfish/jersey/examples/beanvalidation/webapp/MyApplication.java#L94
>
> (btw, consider updating docs).
>
> When I startup servlet container with this Jersey app deployed, my custom
> parameter name provider is sometimes respected, but problem is that
> sometimes in another startup of the container with same unchanged app, a
> default parameter name provider gets used.
>
> Am I doing something wrong? Is this a known bug?
> Any tips how to workaround this problem are more than welcome.
>
> Kind regards,
> Stevo Slavic
>