public void (@Valid Person p) { ... }
我创建了一个测试,并将此方法传递给非有效对象,但没有任何反应.
我希望得到一个例外.
解决方法
例如,如果您在JAX-RS资源类中具有以下方法定义：
@Path("/example")
public class MyExampleResourceImpl {
@POST
@Path("/")
public Response postExample(@Valid final Example example) {
// ....
}
}
当调用postExample方法以响应JAX-RS容器处理的请求时,将验证示例bean.将此行为与运行独立Java SE应用程序时会发生的情况进行对比：
public class MyMainClass {
public static void main(final String[] args) {
final MyMainClass clazz = new MyMainClass();
clazz.echo(new Example());
}
public Example echo(@Valid final Example example) {
// ...
}
}
在这种情况下,即使您包含了所有JSR 303运行时JAR,运行该程序也不会触发Example参数的验证.这是因为没有可用的容器实现方法级别验证. Bean Validation Specification在附录C中详细描述了所有这些.为了您的利益,我在下面引用了一些内容：
Proposal for method-level validation
This proposition has not been integrated into the core specification
and is not part of it. It remains here for archaeological purposes and
will be serIoUsly considered for a future revision of this
specification. This proposal is likely to be a bit out of sync with
the rest of the specification artifacts.Note: Bean Validation providers are free to implement this proposal as
a specific extension. Such specific extension could for example be accessed
via the use of the Validator.unwrap method.A popular demand was to provide a method and parameter level validation
mechanism reusing the constraint descriptions of the specification. This
set of APIs is meant to be used by interceptor frameworks such as:
- application frameworks like
- JSR-299
- component frameworks like Enterprise Java Beans
- aspect based frameworks
These frameworks can call the validation APIs to validate either the parameter list or the returned value of a method when such method is called. More precisely,validation occurs around a method invocation. This extension of the Bean Validation API allows to reuse the core engine as well as the constraint definition and declaration for such method level validations.
