todas - tipos de errores en java
¿Cuál es la mejor manera de suprimir una advertencia de consola de tiempo de ejecución en Java? (7)
Estoy usando el método getResponseBody () de la clase org.apache.commons.httpclient.methods.PostMethod. Sin embargo, siempre recibo un mensaje escrito en la consola en tiempo de ejecución:
ADVERTENCIA: Ir al cuerpo de respuesta de búfer de tamaño grande o desconocido. Se recomienda usar getResponseBodyAsStream en su lugar.
En el código tengo que escribir la respuesta a una matriz de bytes de todos modos, así que es el método getResponseBody () que debo usar. Pero, ¿hay una manera fácil de suprimir el mensaje de advertencia para no tener que verlo en cada ejecución?
Si fuera un error del compilador, usaría la anotación @SuppressWarnings , pero esto no es un problema en tiempo de compilación; sucede en el tiempo de ejecución. Además, podría usar getResponseBodyAsStream para escribir en ByteArrayOutputStream, pero esta parece una forma de piratear la advertencia (líneas de código adicionales para hacer lo que getResponseBody () ya está haciendo por mí).
Mi conjetura es que la respuesta implica la manipulación de System.out o System.err, pero ¿hay una buena manera de hacer esto?
¿La biblioteca está saliendo a través de log4j? si es así, la edición de log4j.properties para establecer el resultado de esta clase en "ERROR" funcionaría, por ejemplo
log4j.logger.org.apache.commons.httpclient.methods.PostMethod=ERROR
Le recomendaría que haga lo que sugiere la advertencia y utilice una secuencia en lugar de una matriz de bytes. Si la respuesta que está intentando enviar es particularmente grande (suponga que es un archivo grande), lo cargará todo en la memoria y eso sería algo muy malo.
Realmente estás mejor usando corrientes.
Dicho esto, puedes hackearlo reemplazando System.err o System.out temporalmente. Son solo objetos de PrintStream
y se pueden configurar con los métodos setOut y setErr.
PrintStream oldErr = System.err;
PrintStream newErr = new PrintStream(new ByteArrayOutputStream());
System.setErr(newErr);
// do your work
System.setErr(oldErr);
Editar:
Estoy de acuerdo en que sería preferible utilizar flujos, pero como está ahora, la API de destino donde debo colocar la respuesta es una matriz de bytes. Si es necesario, podemos hacer un refactor a la API que le permitirá tomar un flujo; eso estaría mejor. La advertencia está definitivamente ahí por una razón.
Si puedes modificar la API, hazlo. El procesamiento de flujo es la mejor manera de ir en este caso. Si no puede debido a las presiones internas o lo que sea, vaya a la ruta de @John M y BUFFER_WARN_TRIGGER_LIMIT
el BUFFER_WARN_TRIGGER_LIMIT
, pero asegúrese de tener una longitud de contenido conocida, o incluso esa ruta fallará.
Si desea detener limpiamente esta entrada de registro, hay un máximo optimizable que activa la advertencia. Vi esto mirando el código .
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 () se ve como el lugar para establecer HttpMethodParams.BUFFER_WARN_TRIGGER_LIMIT en el valor deseado.
Suponiendo que la advertencia se escriba en stderr, siempre puede suprimir la advertencia al colocar stderr en /dev/null
, o lo que sea el equivalente en su sistema.
esa advertencia ocurre cuando httpClient no tiene idea de la longitud de los datos de retorno, debe establecer el atributo de longitud de contenido en el extremo de su servidor
response.addHeader("Content-Type", "text/html; charset=utf-8");
response.addHeader("Content-Length", String.valueOf(output.getBytes("utf8").length));
después de eso, esa advertencia debería desaparecer
para simplemente ''guardar'' los mensajes stderr y luego imprimirlos después de completar la tarea principal
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);
Este problema ya ha sido debatido en el ASF JIRA . Hay dos maneras de resolver esto:
- Establezca un valor más alto para BUFFER_WARN_TRIGGER_LIMIT . Un valor suficientemente alto es más probable que suprima la advertencia; Sin embargo, eso anula el propósito de la propia advertencia. Si está almacenando en búfer una gran cantidad de datos para analizarlos en una sola pasada, es mejor que lea los datos de un flujo en una matriz antes de trabajar en la matriz.
- Establezca el nivel de registro en un valor más alto para HttpClient, si se siente cómodo con ERROR o FATAL.