Given an EJB that extends no interface (uses the no-interface view variant of EJB3.1), any validation annotation put on any parameter on any public method is automatically added to the proxy of that ejb created by the container.
At this moment, hibernate validator complains saying:
Only the root method of an overridden method in an inheritance hierarchy may be annotated with parameter constraints, but there are parameter constraints defined at all of the following overridden methods...
The methods signalled are: the one from the ejb and the one from the proxy.
There is obviously no way around it but to declare an interface for that EJB and move the validation annotations there. An ugly workaround.
Andrei, thanks for your report. Could give some more details (which application server, how do you trigger method validation)? Maybe you could provide a test case showing the problem? Thank you.
I've drilled into the source code today and came to this conclusion: hibernate method validator uses Method.getParameterAnnotations() to fetch the annotations used on a class in order to determine which overridden methods duplicate validation annotations from superclasses.
The problem is that the proxy class generated by the Jboss AS 7.1.1 container has all method parameter annotations from the ejb class copied on its method parameters too! So obviously this is not a normal inheritance and the method validator sees this as a breach of its specifications.
This means that this problem exists not only for no-interface view ejbs but for normal ones too. I checked it and verified that it reproduces for this case too.
To answer your question, I have a setup that includes resteasy and the resteasy-hibernatevalidator-provider. I will provide the test case but if what I said is right, the problem is with the proxy factory in jboss 7.1.1
Andrei, I had a look into your test case but was not able to reproduce the problem. Validation of the EJB method works for me in both cases, when I have an interface for it and also without. Posting an invalid TestBean will cause a MethodValidationException as expected. Could you provide your complete stack trace?
Here it is, sorry it took so much time:
Andrei, could you check with the latest candidate release of Hibernate Validator 5 (5.0.0.CR5)? In 5.x, we have re-worked the check for parameter constraints in sub-classes and there should be no exception anymore in cases where the overriding method exactly defines the same parameter constraints as the method it overrides (which should be the case here). Thanks.