在unix服务器中使用任何shell脚本时，我能够看到esapi jar在控制台上放置一些消息，这使得查看该脚本的输出变得困难。 ESAPI jar中有一些sysout。是否有人知道是否有任何方法可以摆脱它，或者是否有新罐子已经将其移除？
答案 0 :(得分：1)
感谢avgvstvs。即使我得到了Kevin Wall的类似回复。
这实际上是一种捕获22的情况。你这个详细的输出 引用来自DefaultSecurityConfiguration类 搜索正确的ESAPI.properties和validation.properties文件 使用。 catch-22是ESAPI可以使用log4j或java.util.logging， 但是，在找到并解析之前，它还不知道哪个被使用 ESAPI.properties文件（可以位于许多不同的位置）。
因此，我们无法进行这些＆＃34;调试＆＃34;或者更简洁的记录，因为作为人 使用ESAPI，尤其是第一次，经常遇到问题 ESAPI也是 无法找到他们的ESAPI.properties文件或让它找到并使用 与他们的意图不同。特别是，我们不能依赖于使用 ESAPI指定的记录器，因为该信息可能不存在 在ESAPI.properties文件中解析。 （另外，这样做会更紧密 将ESAPI记录器连接到ESAPI配置，这是我们的事情 我想避免。
在这种情况下我们可以做的最好的事情可能是不输出 如果设置了某些系统属性，则为这些消息，例如，如果属性
esapi.configuration.errormessages
被设定为＆＃34;安静＆＃34;或者＆＃34; off＆＃34;等等我们可以避免输出这个。 或者，我们可以在DefaultSecurityConfiguration上提供静态方法 禁用特殊日志记录。
但考虑到人们在实现目标方面遇到的麻烦 ESAPI.properties 文件使用开箱即用，我肯定想保持DEFAULT这样 它打印这些消息。
顺便说一句，我会在GitHub问题＃198中写下这些想法 用它。如果有人有任何更好的想法，请随时提出以下建议： https://github.com/ESAPI/esapi-java-legacy/issues/198。还觉得 免费提供解决此问题的拉取请求。没有保证 我们会接受它，但如果有人帮忙，它更有可能获得 注意，如果没有。祝你好运， -kevin
答案 1 :(得分：0)
这是known issue.对于Kevin Wall的一些历史记录，
这实际上是一种捕获22的情况。这个详细的输出 引用来自DefaultSecurityConfiguration类 因为它正在搜索正确的ESAPI.properties和 要使用的validation.properties文件。 catch-22是ESAPI可以使用的 log4j或java.util.logging，但它不知道是哪个 使用，直到它找到并解析ESAPI.properties文件（可以是 位于许多不同的地方）。
因此，我们无法使用常规的ESAPI日志记录机制 控制日志级别，因为可能尚未解析ESAPI记录器 爱好。
此外，ESAPI新用户询问的最大问题之一 Stack Exchange是如何让ESAPI使用ESAPI.properties文件 他们打算使用它。因此，我不希望这样 默认是默认或者真的可以解决这个问题。
有一些建议的更改，但在下一个版本发布之前我不会指望任何内容。