Обработка искаженного @QueryParam с помощью RESTEasy

Меня немного смущает обработка исключений или ее отсутствие в RESTEasy с JBoss AS7/Wildfly. Я не совсем уверен, в какой именно «домен» попадает обработка исключений.

Это то, что я использую для тестирования:

@GET
@POST
@Path("/test")
@Produces(MediaType.APPLICATION_JSON)
public Response test(@QueryParam("id") final long id) {
    log.info("Incoming request! Wee! With id " + id + "!");

    return Response.ok().build();
}

Все идет нормально. Это ведет себя так, как ожидалось, с localhost/app/rest/test?id=123. Однако, когда я добавляю что-то, что не «вписывается» в параметр, например, localhost/app/rest/test?id=123abc, я получаю длинное исключение от RESTEasy, правильно информирующее меня о том, что оно не вписывается в ожидаемый параметр.

Но я не понимаю, как я могу обработать/перехватить это исключение. Очевидно, я не хотел бы, чтобы 40-строчная трассировка стека попадала в мой основной (или любой другой) журнал, но я сам должен правильно регистрировать ошибки. Мое исследование выявило только общий способ обработки всех исключений типа NumberFormatException, который совершенно не подходит для любого разумного подхода к ведению журнала.

Итак, как я могу справиться с этой проблемой? Поскольку это происходит «вне» моего кода, я не могу точно окружить его с помощью try/catch, а конкретный неверный параметр для конкретного сопоставления REST на самом деле не является чем-то достаточно общим, чтобы написать сопоставитель исключений для всего приложения.


java wildfly resteasy jboss jboss7.x
person Torque    schedule 01.12.2013    source источник
comment
Разве сервер не отвечает ошибкой 4xx?   -  person Matt Ball    schedule 01.12.2013
comment
Это не так, но я считаю, что это действительно легко настроить, поэтому я не спрашивал об этом, так как я ожидаю, что смогу справиться с этой частью без посторонней помощи. Меня беспокоит только обработка исключения на стороне сервера.   -  person Torque    schedule 01.12.2013

Ответы (1)


arrow_upward
0
arrow_downward

Довольно странно, что сервер не отвечает с ошибкой 400. Если вы все еще хотите обрабатывать параметры запроса самостоятельно, вы можете создать фильтр и проверить там все параметры запроса. Это должно выглядеть так:

@Provider
public class PreResourceFilter implements ContainerRequestFilter {
    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {     
        MultivaluedMap<String, String> queryParams = requestContext.getUriInfo().getQueryParameters();
        // here you need to check desired parameters
    }
}
person rand0m86    schedule 05.12.2013