Log4j 可选格式修饰符和 LogFilePatternReceiver 正则表达式匹配

发布于 2024-11-19 17:12:18 字数 1028 浏览 1 评论 0原文

我正在使用 Log4j LogFilePatternReceiver 类来读取一些简单的日志文件,并且想知道是否有任何方法告诉 Log4j 将格式修饰符解释为可选。

例如,假设以下模式:

%r [%t] %p %c %x - %m%n

这匹配字符串

123 [main] INFO org.apache.log4j.whatever x=8 - Just a message.

,但不匹配字符串

123 [main] INFO org.apache.log4j.whatever - Just a message.

(即与上面相同,但没有“x=8”部分)。

有没有办法告诉 Log4j 匹配两者?

在另一个相关说明中,在 LogFilePatternReceiver 的源代码中添加几个额外的打印语句,我发现

Pattern: {%r [%t] %p %c %x - %m%n}
Regex:   {(.*?)[ ]+\[(.*?)\][ ]+(\S*\s*?)[ ]+(\S*\s*?)[ ]+(.*)[ ]+\-[ ]+(.*?)}

大括号只是表示每个表达式的开始/结束而不属于它,只是为了确保有不涉及额外的空格或其他字符。正则表达式由 LogFilePatternReceiver 在其 initialize() 方法的末尾创建。

尝试 regexpal.com 中的正则表达式,我仅得到排除消息的部分的匹配,即匹配是,根据正则表达式,

123 [main] INFO org.apache.log4j.whatever x=8 - 

(末尾有一个空格)。显然,正则表达式需要用 $ 符号关闭才能包含消息。

我在模式定义中犯了任何错误吗?

I am using the Log4j LogFilePatternReceiver class to read some simple log files and was wondering whether there is any way of telling Log4j to interpret a format modifier as optional.

For example, assume the following pattern:

%r [%t] %p %c %x - %m%n

This matches the string

123 [main] INFO org.apache.log4j.whatever x=8 - Just a message.

but not the string

123 [main] INFO org.apache.log4j.whatever - Just a message.

(i.e., same as above, but without the "x=8" part).

Is there any way of telling Log4j to match both?

On another relevant note, putting couple of additional print statements in the source code of LogFilePatternReceiver, I get

Pattern: {%r [%t] %p %c %x - %m%n}
Regex:   {(.*?)[ ]+\[(.*?)\][ ]+(\S*\s*?)[ ]+(\S*\s*?)[ ]+(.*)[ ]+\-[ ]+(.*?)}

where the braces simply denote the start/end of each expression without belonging to it, just to make sure that there are no extra spaces or other characters involved. The regex is created by the LogFilePatternReceiver, at the end of its initialize() method.

Trying the regex in regexpal.com, I get a match only for the part excluding the message, i.e. the match is, according to regexpal,

123 [main] INFO org.apache.log4j.whatever x=8 - 

(with a space in the end). Apparently, the regex needs to be closed with a $ sign for the message to be included.

Am I making any mistake in the pattern definition?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

那小子欠揍 2024-11-26 17:12:18

最后一个括号包含一个惰性量词:.*? 表示“匹配零个或多个字符,尽可能少”。这意味着空字符串是有效的匹配(这在正则表达式的其他部分中有意义,因为后面的内容您不希望被正则表达式的前一部分吞噬)。

使用 .* 代替,这意味着“匹配零个或多个字符,尽可能多”:

(.*?) +\[(.*?)\] +(\S*\s*?) +(\S*\s*?) +(.*) +- +(.*)

The last parentheses enclose a lazy quantifier: .*? means "match zero or more characters, as few as possible". This means that the empty string is a valid match (which makes sense in the other parts of your regex because there is stuff following that you don't want gobbled up by the previous part of your regex).

Use .* instead which means "match zero or more characters, as many as possible":

(.*?) +\[(.*?)\] +(\S*\s*?) +(\S*\s*?) +(.*) +- +(.*)
似梦非梦 2024-11-26 17:12:18

为您的 LogFilePatternReceiver 尝试此 LogFormat(注意 * 通配符)

PROP(RELATIVETIME) [THREAD] LEVEL LOGGER*PROP(X) - MESSAGE

Try this LogFormat for your LogFilePatternReceiver (note the * wildcard)

PROP(RELATIVETIME) [THREAD] LEVEL LOGGER*PROP(X) - MESSAGE

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文