Great. Seems we agree then that this is not a regression, but indeed related to our redefined behavior for method parameter validation.
Regarding the integration stacks - this functionality really doesn't belong to Hibernate Validator directly. Also there is hardly any code per framework. It hardly justifies the release of a jar file for each framework. It's definitely something we can put onto the wiki, but the code itself, not sure. However, this is not really the right place to discuss this. Let's have a discussion on hibernate-dev and/or open a new Jira issue.

However it does not seem consistent - the declarations for return types are not covered in the same manner - see updated testcase where return value constraints are still left on the concrete class - but still passes.

This is because a strengthening of postconditions in sub-types is no problem in programming by contract. A client of a method just might get more guarantees for the return value than he had expected, but that's fine. This is also consistent with getter based property constraints, there the constraints in a hierarchy are conjoined, too.

BTW: How about distributing https://github.com/gunnarmorling/methodvalidation-integration as hibernate-validator-aspects?

Yepp, this might be an idea. I'm not quite sure how to proceed with the integration project. If you're using Seam/CDI, there is Seam Validation but we surely need to find a solution for other stacks, too.

BTW: How about distributing https://github.com/gunnarmorling/methodvalidation-integration as hibernate-validator-aspects? Then I could nuke my own

Right - declaring them at top-level - and in this case - at interface level - makes sense.
However it does not seem consistent - the declarations for return types are not covered in the same manner - see updated testcase where return value constraints are still left on the concrete class - but still passes.

I read the blog post when I upgraded at 1st - and tried changing it - but it must have been for one of the return tests - and not the entry ones.

This is indeed caused by HV-421. The problem is that DummyServiceImpl#doFailWithEmptyArg() adds a parameter constraint to DummyService#doFailWithEmptyArg(). Following to the Programming by Contract definition such a strengething of a method's precondition in sub-types is not allowed. The reason is that a client (in your case ValidationAspectTest) only sees the base type and can't know about the additional constraints from the sub-type/implementation.

We settled on a conservative approach for this in HV 4.2 and allow parameter constraints only at the highest declaration of a method in an inheritance hierarchy, in your case DummyService. That way the client clearly sees the preconditions he has to fulfull when invoking a given method.

Actually the stacktrace is saying this:

I'll try to make this message a bit clearer, there should only the problematic method be mentioned, not the internally used MethodMetaData object.

You can find more information on this topic and the discussion which led to the current approach at and in the announcement for Beta2.