在Unix服务器中使用Shell脚本时，esapi jar在控制台上放置一些消息（系统输出）

Question

When using any shell script in unix server, I am able to see esapi jar puts some message on console making it little difficult to see the output of that script. ESAPI jar has some sysout in it. Is anyone aware if there is any way to get rid of it or if there is new jar which has already removed it?

Answer 1

Thanks avgvstvs. Even I got similar reply from Kevin Wall.

---

This is really somewhat of a catch-22 situation. This verbose output that you refer to comes from the DefaultSecurityConfiguration class as it is searching for the correct ESAPI.properties and validation.properties files to use. The catch-22 is that ESAPI can use either log4j or java.util.logging, but it doesn't know which is being used until if finds and parses the ESAPI.properties file (which can be located in many different places).

Thus we can't make these "debug" or less verbose logging because as people using ESAPI, especially for the first time, often have problems with ESAPI either not being able to find their ESAPI.properties file or having it locate and use a different on than what they intended. In particular, we can't rely on using the logger that ESAPI specifies because that information may not have been parsed yet in the ESAPI.properties file. (Also, doing so would more tightly couple the ESAPI logger to the ESAPI configuration, something that we would like to avoid.

Probably about the best we could do in this case would be to NOT output these messages if some System property was set, eg, if the property

esapi.configuration.errormessages

were set to "quiet" or "off", etc. then we could refrain from outputting this. Alternately, we could provide a static method on DefaultSecurityConfiguration that disables the special logging.

But given the trouble that people have with getting their intended ESAPI.properties file used out-of-the-box, I would definitely want to keep the DEFAULT so that it prints these messages.

BTW, I will write up these ideas in the GitHub issue # 198 that deals with it. If anyone has any better ideas, feels free to contribute ideas at: https://github.com/ESAPI/esapi-java-legacy/issues/198 . Also feel free to contribute a pull request that addresses this. No guarantees that we will accept it, but if someone helps out, it is more likely to get attention than if not.

Best regards, -kevin

Answer 2

This is a known issue. For some of the history from Kevin Wall,

This is really somewhat of a catch-22 situation. This verbose output that is refered to comes from the DefaultSecurityConfiguration class as it is searching for the correct ESAPI.properties and validation.properties files to use. The catch-22 is that ESAPI can use either log4j or java.util.logging, but it doesn't know which is being used until it finds and parses the ESAPI.properties file (which can be located in many different places).

Because of this, we can't use the regular ESAPI logging mechanism to control the log level as the ESAPI logger may not have been parsed yet.

Also, one of the biggest problems that new users to ESAPI ask about in Stack Exchange is how to get ESAPI to use the ESAPI.properties file that they intend it to use. So because of that, I don't want the default to be silent or that will really excerbate that problem.

There is some proposed changes, but I wouldn't expect anything until the next release.