What's the best way to suppress a runtime console warning in Java?

耗尽温柔 提交于 2019-12-03 05:07:19
Randolpho

I would recommend that you do as the warning suggests and use a stream rather than a byte array. If the response you're trying to push is particularly large (suppose it's a large file), you will load it all into memory, and that'd be a very bad thing.

You're really better off using streams.

That said, you might hack around it by replacing System.err or System.out temporarily. They're just PrintStream objects, and they're settable with the setOut and setErr methods.

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

// do your work

System.setErr(oldErr);

Edit:

I agree that it would be preferable to use streams, but as it is now, the target API where I need to put the response is a byte array. If necessary, we can do a refactor to the API that will allow it to take a stream; that would be better. The warning is definitely there for a reason.

If you can modify the API, do so. Stream processing is the best way to go in this case. If you can't due to internal pressures or whatever, go @John M's route and pump up the BUFFER_WARN_TRIGGER_LIMIT -- but make sure you have a known contentLength, or even that route will fail.

If you want to cleanly stop this log entry, there's a tunable max that triggers the warning. I saw this looking at the code.

        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() looks like the place to set HttpMethodParams.BUFFER_WARN_TRIGGER_LIMIT to the desired value.

that warning happends when httpClient have no idea about the length of the return data you should set the content-length attribute in your server end

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

after that, that warning should disapear

Is the library outputting through log4j? if so, editing the log4j.properties to set the output for this class to "ERROR" would work, e.g.

log4j.logger.org.apache.commons.httpclient.methods.PostMethod=ERROR

This issue has already been debated on the ASF JIRA. There are two ways to resolve this:

  • Set a higher value for BUFFER_WARN_TRIGGER_LIMIT. A high enough value is more likely to suppress the warning; however, that defeats the purpose of the warning itself. If you are buffering a lot of data to be eventually parsed in one pass, you are better off reading the data from a stream into an array before working on the array.
  • Set the logging level to a higher value for HttpClient, if you are comfortable with ERROR or FATAL.

Assuming the warning is written to stderr, you can always suppress the warning by piping stderr to /dev/null, or whatever the equivalent on your system is.

to simply 'save' the stderr messages then print them after completion of the main task

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);
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!