我过去已经两次接触过这个主题。 首先，在我的文章《 在Java EE 6中将Bean验证与JAX-RS集成》中 ，介绍了甚至在Java EE平台规范中未定义之前，如何在JBoss AS 7中将Bean验证与JAX-RS结合使用的方法。 后来，在一篇为《 JAX Magazine 》撰写并随后发表在《 JAXenter 》上的文章中，使用了带有Glassfish 4服务器（第一台经过Java EE 7认证的服务器）的Java EE 7中定义的新标准方式。
现在，以前称为JBoss Application Server的WildFly 8终于达到了最终版本，并加入了Java EE 7认证的服务器俱乐部，现在该发表新文章了，重点介绍了这两个应用服务器GlassFish 4和WildFly之间的特性和差异。 8。
规格和API
Java EE 7是期待已久的Java EE 6的重大改进。随着Java EE的每个发行版，都添加了新功能并增强了现有规范。 Java EE 7以Java EE 6的成功为基础，并继续致力于提高开发人员的生产力。
JAX-RS是RESTful Web服务的Java API，是Java EE领域中发展最快的API之一。 当然，这是由于基于REST的Web服务的大量采用以及使用这些服务的应用程序数量的增加。
这篇文章将介绍配置REST端点以支持JavaScript客户端以及处理验证异常以将本地化错误消息发送给客户端（除了HTTP错误状态代码）所需的步骤。
源代码
Bean验证简介
JavaBeans Validation（ Bean验证 ）是一种新的验证模型，可作为Java EE 6平台的一部分使用。 约束条件支持Bean验证模型，该约束以注释的形式出现在JavaBeans组件（例如托管Bean）的字段，方法或类上。
javax.validation.constraints包中提供了一些内置约束。 Java EE 7教程包含具有所有这些约束的列表。
Bean验证中的约束通过Java注释表示：
public class Person {
@NotNull
@Size(min = 2, max = 50)
private String name;
// ...
}Bean验证和RESTful Web服务
JAX-RS为提取请求值并将其绑定到Java字段，属性和参数（使用@HeaderParam ， @QueryParam等注释）提供了强大的支持。它还支持通过非注释参数将请求实体主体绑定到Java对象（即，未使用任何JAX-RS批注进行批注的参数）。 但是，在JAX-RS 2.0之前，必须以编程方式对资源类中的这些值进行任何其他验证。
最新版本的JAX-RS 2.0提供了一种解决方案，使验证批注可以与JAX-RS批注结合使用。
以下示例显示了如何使用@Pattern验证批注来验证路径参数：
@GET
@Path("{id}")
public Person getPerson(
@PathParam("id")
@Pattern(regexp = "[0-9]+", message = "The id must be a valid number")
String id) {
return persons.get(id);
} 除了验证单个字段外，您还可以使用@Valid批注验证整个实体。
例如，下面的方法接收一个Person对象并对其进行验证：
@POST
public Response validatePerson(@Valid Person person) {
// ...
}国际化
在前面的示例中，我们使用了默认或硬编码的错误消息，但这既是一种不好的做法，又一点也不灵活。 I18n是Bean验证规范的一部分，它使我们能够使用资源属性文件来指定自定义错误消息。 默认资源文件名称为ValidationMessages.properties并且必须包含属性/值对，例如：
person.id.notnull=The person id must not be null
person.id.pattern=The person id must be a valid number
person.name.size=The person name must be between {min} and {max} chars long 注意： {min}和{max}是指与消息相关联的约束的属性。
一旦定义，这些消息就可以注入到验证约束中，例如：
@POST
@Path("create")
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response createPerson(
@FormParam("id")
@NotNull(message = "{person.id.notnull}")
@Pattern(regexp = "[0-9]+", message = "{person.id.pattern}")
String id,
@FormParam("name")
@Size(min = 2, max = 50, message = "{person.name.size}")
String name) {
Person person = new Person();
person.setId(Integer.valueOf(id));
person.setName(name);
persons.put(id, person);
return Response.status(Response.Status.CREATED).entity(person).build();
} 要提供其他语言的翻译，必须使用翻译后的消息创建一个新文件ValidationMessages_XX.properties ，其中XX是所提供语言的代码。
不幸的是，对于某些应用程序服务器，默认的Validator提供程序不基于特定的HTTP请求支持i18n。 他们不考虑Accept-Language HTTP标头，并且始终使用Locale.getDefault()提供的默认Locale 。 为了能够使用Accept-Language HTTP标头（映射到浏览器选项中配置的语言）来更改Locale ，您必须提供一个自定义实现。
自定义验证器提供程序
尽管WildFly 8正确使用Accept-Language HTTP标头来选择正确的资源包，但其他服务器（例如GlassFish 4）却不使用此标头。 因此，为了完整性和与GlassFish代码的比较（在同一个GitHub项目下提供 ），我还为WildFly实现了自定义Validator提供程序。
如果要查看GlassFish示例，请访问JAXenter上的Bean验证与JAX-RS集成。
- 将RESTEasy依赖项添加到Maven
WildFly使用RESTEasy ，这是JAX-RS规范的JBoss实现。
验证程序提供程序和Exception Mapper必需具有RESTEasy依赖关系，本文稍后将对此进行讨论。 让我们将其添加到Maven：<dependencyManagement> <dependencies> <dependency> <groupId>org.jboss.resteasy</groupId> <artifactId>resteasy-bom</artifactId> <version>3.0.6.Final</version> <scope>import</scope> <type>pom</type> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.jboss.resteasy</groupId> <artifactId>resteasy-jaxrs</artifactId> <scope>provided</scope> </dependency> <dependency> <groupId>org.jboss.resteasy</groupId> <artifactId>resteasy-validator-provider-11</artifactId> <scope>provided</scope> </dependency> </dependencies>- 创建一个ThreadLocal来存储
Locale从Accept-LanguageHTTP标头 ThreadLocal变量与普通变量不同，每个访问线程的线程都有其自己的，独立初始化的变量副本。
/** * {@link ThreadLocal} to store the Locale to be used in the message interpolator. */ public class LocaleThreadLocal { public static final ThreadLocal<Locale> THREAD_LOCAL = new ThreadLocal<Locale>(); public static Locale get() { return (THREAD_LOCAL.get() == null) ? Locale.getDefault() : THREAD_LOCAL.get(); } public static void set(Locale locale) { THREAD_LOCAL.set(locale); } public static void unset() { THREAD_LOCAL.remove(); } }- 创建一个请求过滤器以读取
Accept-LanguageHTTP标头 请求过滤器负责读取客户端在
Accept-LanguageHTTP标头中发送的第一语言并将Accept-LanguageLocale存储在我们的ThreadLocal：/** * Checks whether the {@code Accept-Language} HTTP header exists and creates a {@link ThreadLocal} to store the * corresponding Locale. */ @Provider public class AcceptLanguageRequestFilter implements ContainerRequestFilter { @Context private HttpHeaders headers; @Override public void filter(ContainerRequestContext requestContext) throws IOException { if (!headers.getAcceptableLanguages().isEmpty()) { LocaleThreadLocal.set(headers.getAcceptableLanguages().get(0)); } } }- 创建自定义消息插值器以强制执行特定的
Locale 接下来，创建一个自定义消息插值器，以通过绕过或覆盖默认的
Locale策略来强制执行特定的Locale值：/** * Delegates to a MessageInterpolator implementation but enforces a given Locale. */ public class LocaleSpecificMessageInterpolator implements MessageInterpolator { private final MessageInterpolator defaultInterpolator; public LocaleSpecificMessageInterpolator(MessageInterpolator interpolator) { this.defaultInterpolator = interpolator; } @Override public String interpolate(String message, Context context) { return defaultInterpolator.interpolate(message, context, LocaleThreadLocal.get()); } @Override public String interpolate(String message, Context context, Locale locale) { return defaultInterpolator.interpolate(message, context, locale); } }- 配置验证器提供程序
RESTEasy通过查找实现
ContextResolver<GeneralValidator>的提供程序来获得Bean验证实现。
要配置新的验证服务提供者以使用我们的自定义消息插值器，请添加以下内容：/** * Custom configuration of validation. This configuration can define custom: * <ul> * <li>MessageInterpolator - interpolates a given constraint violation message.</li> * <li>TraversableResolver - determines if a property can be accessed by the Bean Validation provider.</li> * <li>ConstraintValidatorFactory - instantiates a ConstraintValidator instance based off its class. * <li>ParameterNameProvider - provides names for method and constructor parameters.</li> * * </ul> */ @Provider public class ValidationConfigurationContextResolver implements ContextResolver<GeneralValidator> { /** * Get a context of type {@code GeneralValidator} that is applicable to the supplied type. * * @param type the class of object for which a context is desired * @return a context for the supplied type or {@code null} if a context for the supplied type is not available from * this provider. */ @Override public GeneralValidator getContext(Class<?> type) { Configuration<?> config = Validation.byDefaultProvider().configure(); BootstrapConfiguration bootstrapConfiguration = config.getBootstrapConfiguration(); config.messageInterpolator(new LocaleSpecificMessageInterpolator(Validation.byDefaultProvider().configure() .getDefaultMessageInterpolator())); return new GeneralValidatorImpl(config.buildValidatorFactory(), bootstrapConfiguration.isExecutableValidationEnabled(), bootstrapConfiguration.getDefaultValidatedExecutableTypes()); } }
映射异常
默认情况下，当验证失败时，容器将引发异常，并将HTTP错误返回给客户端。
Bean验证规范定义了小的异常层次结构（它们都继承自ValidationException ），可以在验证引擎初始化期间或（在我们的情况下更重要）在输入/输出值验证期间抛出异常（ ConstraintViolationException ）。 如果抛出的异常是ValidationException的子类（ ConstraintViolationException除外），则此异常将映射到状态码为500（内部服务器错误）的HTTP响应。 另一方面，当抛出ConstraintViolationException时，将返回两个不同的状态代码：
- 500内部服务器错误）
如果在验证方法返回类型时引发了异常。 - 400（错误请求）
除此以外。
不幸的是，WildFly并没有抛出ConstraintViolationException异常以获取无效的输入值， ResteasyViolationException抛出了ResteasyViolationException ，该异常实现了ValidationException接口。
可以自定义此行为，以允许我们将错误消息添加到返回给客户端的响应中：
/**
* {@link ExceptionMapper} for {@link ValidationException}.
* <p>
* Send a {@link ViolationReport} in {@link Response} in addition to HTTP 400/500 status code. Supported media types
* are: {@code application/json} / {@code application/xml} (if appropriate provider is registered on server).
* </p>
*
* @see org.jboss.resteasy.api.validation.ResteasyViolationExceptionMapper The original WildFly class:
* {@code org.jboss.resteasy.api.validation.ResteasyViolationExceptionMapper}
*/
@Provider
public class ValidationExceptionMapper implements ExceptionMapper<ValidationException> {
@Override
public Response toResponse(ValidationException exception) {
if (exception instanceof ConstraintDefinitionException) {
return buildResponse(unwrapException(exception), MediaType.TEXT_PLAIN, Status.INTERNAL_SERVER_ERROR);
}
if (exception instanceof ConstraintDeclarationException) {
return buildResponse(unwrapException(exception), MediaType.TEXT_PLAIN, Status.INTERNAL_SERVER_ERROR);
}
if (exception instanceof GroupDefinitionException) {
return buildResponse(unwrapException(exception), MediaType.TEXT_PLAIN, Status.INTERNAL_SERVER_ERROR);
}
if (exception instanceof ResteasyViolationException) {
ResteasyViolationException resteasyViolationException = ResteasyViolationException.class.cast(exception);
Exception e = resteasyViolationException.getException();
if (e != null) {
return buildResponse(unwrapException(e), MediaType.TEXT_PLAIN, Status.INTERNAL_SERVER_ERROR);
} else if (resteasyViolationException.getReturnValueViolations().size() == 0) {
return buildViolationReportResponse(resteasyViolationException, Status.BAD_REQUEST);
} else {
return buildViolationReportResponse(resteasyViolationException, Status.INTERNAL_SERVER_ERROR);
}
}
return buildResponse(unwrapException(exception), MediaType.TEXT_PLAIN, Status.INTERNAL_SERVER_ERROR);
}
protected Response buildResponse(Object entity, String mediaType, Status status) {
ResponseBuilder builder = Response.status(status).entity(entity);
builder.type(MediaType.TEXT_PLAIN);
builder.header(Validation.VALIDATION_HEADER, "true");
return builder.build();
}
protected Response buildViolationReportResponse(ResteasyViolationException exception, Status status) {
ResponseBuilder builder = Response.status(status);
builder.header(Validation.VALIDATION_HEADER, "true");
// Check standard media types.
MediaType mediaType = getAcceptMediaType(exception.getAccept());
if (mediaType != null) {
builder.type(mediaType);
builder.entity(new ViolationReport(exception));
return builder.build();
}
// Default media type.
builder.type(MediaType.TEXT_PLAIN);
builder.entity(exception.toString());
return builder.build();
}
protected String unwrapException(Throwable t) {
StringBuffer sb = new StringBuffer();
doUnwrapException(sb, t);
return sb.toString();
}
private void doUnwrapException(StringBuffer sb, Throwable t) {
if (t == null) {
return;
}
sb.append(t.toString());
if (t.getCause() != null && t != t.getCause()) {
sb.append('[');
doUnwrapException(sb, t.getCause());
sb.append(']');
}
}
private MediaType getAcceptMediaType(List<MediaType> accept) {
Iterator<MediaType> it = accept.iterator();
while (it.hasNext()) {
MediaType mt = it.next();
/*
* application/xml media type causes an exception:
* org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response
* object of type: org.jboss.resteasy.api.validation.ViolationReport of media type: application/xml
*/
/*if (MediaType.APPLICATION_XML_TYPE.getType().equals(mt.getType())
&& MediaType.APPLICATION_XML_TYPE.getSubtype().equals(mt.getSubtype())) {
return MediaType.APPLICATION_XML_TYPE;
}*/
if (MediaType.APPLICATION_JSON_TYPE.getType().equals(mt.getType())
&& MediaType.APPLICATION_JSON_TYPE.getSubtype().equals(mt.getSubtype())) {
return MediaType.APPLICATION_JSON_TYPE;
}
}
return null;
}
} 上面的示例是ExceptionMapper接口的实现，该接口映射ValidationException类型的异常。 验证失败时，Validator实现将引发此异常。 如果该异常是ResteasyViolationException的实例， ResteasyViolationException除了HTTP 400/500状态代码外，我们ResteasyViolationException在响应中发送ViolationReport 。 这样可以确保客户端收到格式化的响应，而不仅仅是从资源传播的异常。
产生的输出类似于以下内容（JSON格式）：
{
"exception": null,
"fieldViolations": [],
"propertyViolations": [],
"classViolations": [],
"parameterViolations": [
{
"constraintType": "PARAMETER",
"path": "getPerson.id",
"message": "The id must be a valid number",
"value": "test"
}
],
"returnValueViolations": []
}运行和测试
要运行本文使用的应用程序，请使用Maven构建项目，将其部署到WildFly 8应用程序服务器中，然后将浏览器指向http：// localhost：8080 / jaxrs-beanvalidation-javaee7 / 。
另外，您也可以运行在类中的测试PersonsIT其内置的Arquillian和JUnit的 。 Arquillian将自动启动嵌入式WildFly 8容器，因此请确保您没有在同一端口上运行其他服务器。
建议和改进
- 为了实现自定义的验证程序提供程序，我们依赖于应用程序服务器代码。 在GlassFish 4上，需要实现ContextResolver
ContextResolver<ValidationConfig>，而在WildFly 8上，我们需要实现ContextResolver<GeneralValidator>。 为什么不在Java EE 7规范中定义ValidationConfig和GeneralValidator必须实现的接口，而不是依赖于应用程序服务器特定的代码？ - 使WildFly 8 Embedded易于使用和通过Maven进行配置。 当前，要使Arquillian可以使用它，需要下载WildFly发行版（org.wildfly：wildfly-dist），将其解压缩到
target文件夹中，并在Surefire / Failsafe Maven插件上配置系统属性：<systemPropertyVariables> <java.util.logging.manager>org.jboss.logmanager.LogManager</java.util.logging.manager> <jboss.home>${wildfly.home}</jboss.home> <module.path>${wildfly.home}/modules</module.path> </systemPropertyVariables>而对于Glassfish，您只需要定义正确的依赖项（org.glassfish.main.extras：glassfish-embedded-all）。
- 使RESTEasy成为WildFly Embedded的可传递依赖项。 仅通过定义
providedWildFly Embedded依赖项，在编译时就可以使用所有WildFly模块，这将是一个很好的生产力提升。 - 当前无法在Eclipse上使用选项
Run As>>JUnit Test，因为必须存在名为jbossHome的系统属性。 Eclipse不会从Surefire / Failsafe配置中读取此属性。 有没有解决方法？ - 当使用RESTEasy的
ExceptionMapper<ValidationException>默认实现时，以application/xml媒体类型请求数据并发生验证错误，将引发以下异常：org.jboss.resteasy.core.NoMessageBodyWriterFoundFailure: Could not find MessageBodyWriter for response object of type: org.jboss.resteasy.api.validation.ViolationReport of media type: application/xml这是RESTEasy错误吗？
498
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
