I'm probably one of the many that is moving away from Glassfish to WildFly. I have done some trivial changes but now Weld is giving validation failures like the following on some of our EJB3 beans: javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not alter the parameter constraint configuration The worse thing is that only see one at a time: so I fix one, do the build-redeploy dance, and then see the next one. Most of the problems is that in the overriding class we use javax.validation.constraints.NotNull annotation on the parameter, which is what Weld doesn't seem to like. Obviously these worked in Glassfish. My first thought is: how can I shut off Weld validation? If that is not possible (which I'm willing to accept), then how can I see these validation errors all at once instead of one at a time during deployment? Thanks -- Mike Hostetler http://mike.hostetlerhome.com/

_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hi Mike, a couple of more remarks on top of Emmanuel's. First of all, as Emmanuel is saying method and constructor validation should behave the same on Glassfish and Wildfly. The Bean Validation specification (part of EE 7) says that method and constructor validation occurs per default as soon as Bean Validation constraint annotations are used on methods or constructors. You find the relevant specification section here - http://beanvalidation.org/1.1/spec/#integration-general-executable To answer your question on how to disable validation. You can add a validation.xml file disabling executable validation: <?xml version="1.0" encoding="UTF-8"?> <validation-config xmlns=" http://jboss.org/xml/ns/javax/validation/configuration" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://jboss.org/xml/ns/javax/validation/configurationvalidation-configur... version="1.1"> <executable-validation enabled="false"/> </validation-config> Last but not least, open an issue with test case, so that we can check whether there is a bug or not. --Hardy On 26 Jan 2014, at 16:40, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > Does your offending method actually override another method? > Because that would definitely be an error on your part. > Glassfish uses Hibernate Validator for the validation engine so I don't > think your code is at fault here. Unless they have a broken integration > and nothing is validated. > > But it could be due to a bug on how Weld does subclassing for proxies and > copy constraint annotations but I thought we had that base covered > already. > > The best would be to open an issue with a reproducible minimal test > case. From there we could either fix the offending bug and if there is > none see how we could report several errors in one go. > > Emmanuel > > On Wed 2014-03-26 10:16, Mike Hostetler wrote: >> I'm probably one of the many that is moving away from Glassfish to WildFly. >> I have done some trivial changes but now Weld is giving validation failures >> like the following on some of our EJB3 beans: >> >> javax.validation.ConstraintDeclarationException: HV000151: A method >> overriding another method must not alter the parameter constraint >> configuration >> >> The worse thing is that only see one at a time: so I fix one, do the >> build-redeploy dance, and then see the next one. Most of the problems is >> that in the overriding class we use javax.validation.constraints.NotNull >> annotation on the parameter, which is what Weld doesn't seem to like. >> Obviously these worked in Glassfish. >> >> My first thought is: how can I shut off Weld validation? If that is not >> possible (which I'm willing to accept), then how can I see these validation >> errors all at once instead of one at a time during deployment? >> >> Thanks >> -- >> Mike Hostetler >> http://mike.hostetlerhome.com/ > >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev