Какой лучший способ подавить предупреждение консоли времени выполнения в Java? - PullRequest
17 голосов
/ 13 апреля 2009

Я использую метод getResponseBody () класса org.apache.commons.httpclient.methods.PostMethod. Тем не менее, я всегда получаю сообщение, записанное на консоль во время выполнения:

ПРЕДУПРЕЖДЕНИЕ. Переход к буферному телу ответа большого или неизвестного размера. Вместо этого рекомендуется использовать getResponseBodyAsStream.

В коде я все равно должен написать ответ в байтовый массив, поэтому мне следует использовать метод getResponseBody (). Но есть ли простой способ, которым я могу подавить предупреждающее сообщение, чтобы мне не приходилось смотреть на него при каждом запуске?

Если бы это была ошибка компилятора, я бы использовал аннотацию @ SuppressWarnings , но это не проблема времени компиляции; это происходит во время выполнения. Кроме того, я мог бы использовать getResponseBodyAsStream для записи в ByteArrayOutputStream, но это похоже на хакерский способ обойти предупреждение (дополнительные строки кода делают то, что getResponseBody () уже делает для меня).

Я предполагаю, что ответ связан с манипуляциями System.out или System.err, но есть ли хороший способ сделать это?

Ответы [ 7 ]

19 голосов
/ 13 апреля 2009

Если вы хотите аккуратно остановить эту запись в журнале, есть настраиваемый максимум, который выдает предупреждение. Я видел это глядя на код .

        int limit = getParams().getIntParameter(HttpMethodParams.BUFFER_WARN_TRIGGER_LIMIT, 1024*1024);
        if ((contentLength == -1) || (contentLength > limit)) {
            LOG.warn("Going to buffer response body of large or unknown size. "
                    +"Using getResponseBodyAsStream instead is recommended.");
        }

HttpMethodBase.setParams () выглядит как место для установки HttpMethodParams.BUFFER_WARN_TRIGGER_LIMIT в желаемое значение.

12 голосов
/ 22 июля 2011

это предупреждение возникает, когда httpClient не имеет представления о длине возвращаемых данных Вы должны установить атрибут content-length в конце вашего сервера

response.addHeader("Content-Type", "text/html; charset=utf-8");
response.addHeader("Content-Length", String.valueOf(output.getBytes("utf8").length));

после этого, это предупреждение должно исчезнуть

11 голосов
/ 13 апреля 2009

Я бы порекомендовал вам сделать так, как предлагает предупреждение, и использовать поток, а не байтовый массив. Если ответ, который вы пытаетесь выдвинуть, особенно велик (предположим, это большой файл), вы загрузите все это в память, и это было бы очень плохо.

Вам действительно лучше использовать потоки.

Тем не менее, вы можете взломать его, временно заменив System.err или System.out. Это просто PrintStream объекты, и они устанавливаются с помощью методов setOut и setErr.

PrintStream oldErr = System.err;
PrintStream newErr = new PrintStream(new ByteArrayOutputStream());
System.setErr(newErr);

// do your work

System.setErr(oldErr);

Edit:

Я согласен, что было бы предпочтительнее использовать потоки, но, как сейчас, целевой API, где мне нужно поставить ответ является байтовым массивом. Если необходимо, мы можем сделать рефакторинг к API, который позволит ему принять поток; это было бы лучше. предупреждение определенно есть для причина.

Если вы можете изменить API, сделайте это. Потоковая обработка - лучший способ пойти в этом случае. Если вы не можете этого сделать из-за внутреннего давления или чего-то подобного, пройдите по маршруту @ John M и накачайте BUFFER_WARN_TRIGGER_LIMIT - но убедитесь, что у вас есть известная длина контента, или даже этот маршрут потерпит неудачу.

8 голосов
/ 13 апреля 2009

Выводится ли библиотека через log4j? если это так, будет работать редактирование log4j.properties для установки вывода для этого класса на «ОШИБКА», например,

log4j.logger.org.apache.commons.httpclient.methods.PostMethod=ERROR
4 голосов
/ 14 апреля 2009

Эта проблема уже обсуждалась на ASF JIRA . Есть два способа решить эту проблему:

  • Установите более высокое значение для BUFFER_WARN_TRIGGER_LIMIT . Достаточно высокое значение с большей вероятностью подавит предупреждение; однако это противоречит цели самого предупреждения. Если вы буферизуете большой объем данных для последующего анализа за один проход, лучше прочитать данные из потока в массив, прежде чем работать с ним.
  • Установите для уровня протоколирования более высокое значение для HttpClient, если вам удобны ошибки ERROR или FATAL.
1 голос
/ 04 июля 2011

, чтобы просто «сохранить» сообщения stderr, а затем распечатать их после завершения основной задачи

PrintStream origErr = System.err;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream newErr = new PrintStream(baos);
System.setErr(newErr);

====== do stuff ======

System.setErr(origErr);
System.err.print(baos);
1 голос
/ 13 апреля 2009

Предполагая, что предупреждение записано в stderr, вы всегда можете подавить предупреждение, отправив в stderr значение /dev/null или любой эквивалент в вашей системе.

...