Nested parenthesis cannot be parsed; seems pattern has no concept of nesting and will end prematurely

[WesternGun]

I have logs lines with (%t) like:

(Camel (camel-1) thread #17 - Split)

or

(Camel (camel-1) thread #4 - JmsConsumer[my.queue])

I see that chainsaw will stop parsing the thread name at the first right parenthesis, and consider the rest as next token. I think it should consider the levels and save them in a stack, sth like:

• push the left parenthesis into a stack
• whenever it sees a right parenthesis, pops out a left paring one
• if stack is not empty, continue parsing this token.

Now the workaround is to change the log format to be like -{%t}-, and configure chainsaw to be the same. That is fine at dev time, but will not solve production issue when the format is fixed.

[rm5248]

Do you need to parse text lines? The version of chainsaw in master(likely somewhat unstable) does have some initial support for JSON based log messages, which would bypass this problem.

[WesternGun]

No, this is not a JSON log, but text lines. I could change Quarkus to output JSON format, but I would rather not; and I need to analyze other applications' logs which are not Quarkus based and they only have text line logs(cannot use JSON).

I think even for plain text logs, this should be checked. But I agree that things would become complicated as you may need to do this stack pop/push whenever you see a parenthesis/bracket/curly bracket in the pattern, in each field.