Thanks @Volkan! I'll raise a JIRA ticket.
Also thanks @Damien for the pointer on %xEx (before starting this
thread I did look up the mail archives but could not find your thread
- possibly my inexperience with the filtering).
Given that the feature is already supported in
ExtendedThrowablePatternConverter, I believe the proper "fix" here
would be to update the documentation to point to %xEx for
{filters(..)} syntax/usage (since filtering stack frames is actually
not a common requirement, bringing the feature into %ex might be an
unnecessary overhead after all). WDYT?
On 2/16/22, Volkan Yazıcı <vol...@yazi.ci> wrote:
> Hello Janaka & Damien,
>
> This discrepancy indeed seems like a bug. Would you mind first filing a
> JIRA ticket, please?
>
> @Janaka, if you can contribute this feature in a PR that would be great! To
> avoid redundant iterations, would you mind briefly describing how you plan
> to address the issue in the ticket before starting to implement anything,
> please?
>
> Cheers!
>
> On Mon, Feb 14, 2022 at 11:00 PM Damien Jiang <damien@swarm.space.invalid>
> wrote:
>
>> I also sent a message to the mailing list about this 4 days before:
>> https://lists.apache.org/thread/yoj9bdfqfph6q03t26r5mrdc37zjd9nw
>> but there's been no response yet.
>>
>> For now I just started using %xEx, but I'd appreciate it if this feature
>> could be supported for %ex as well.
>>
>> Thanks,
>> Damien
>>
>> On Sun, Feb 13, 2022 at 6:40 PM Janaka Bandara
>> <janakaud+apa...@gmail.com>
>> wrote:
>>
>> > Hello everyone,
>> >
>> > PatternLayout (
>> > https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout)
>> > advertises this parameter syntax, to allow filtering undesired stack
>> > frames from logged stacktraces: `%ex{filters(package,list)}`
>> >
>> > > ex|exception|throwable
>> > >
>> > > {filters(package,package,...)}
>> > >
>> > > Use {filters(packages)} where packages is a list of package names to
>> > suppress matching stack frames from stack traces.
>> >
>> >
>> > However on 2.17.1 (latest) when I use such a pattern:
>> >
>> > `<PatternLayout pattern="%d{ISO8601} %5p %c{1}
>> %m%n%ex{filters(org.p2)}"/>`
>> >
>> > no filtering happens, and I still get stacktraces like:
>> >
>> > ```
>> > 2022-02-14T07:25:23,048 ERROR TestLog error
>> > java.lang.IllegalStateException: Oh no
>> > at org.p2.Foo.run(Foo.java:5)
>> > at com.p1.Bar.run(Bar.java:7)
>> > at org.p2.Bar.run(Bar.java:5)
>> > at com.p1.Foo.run(Foo.java:7)
>> > at TestLog.main(TestLog.java:11)
>> > ```
>> >
>> >
>> > Per my understanding, above config should remove the two `at
>> > org.p2...` frames/lines from the stacktrace.
>> >
>> > Turning off `alwaysWriteExceptions` makes no change.
>> >
>> >
>> > Looking at the
>> >
>> `org.apache.logging.log4j.core.impl.ThrowableFormatOptions#newInstance(..)`
>> > codebase I see that the `filters` parameter is parsed and loaded to
>> > `ThrowableFormatOptions` properly; but in the actual
>> >
>> >
>> `org.apache.logging.log4j.core.pattern.ThrowablePatternConverter#formatOption(..)`
>> > I cannot find any stack frame filtering logic using `filters` config.
>> > So to me it seems like `filters` functionality is not yet implemented
>> > (although I could not find any documentation/discussions to back my
>> > suspicion).
>> >
>> >
>> > I would be happy to contribute a filtering implementation honoring the
>> > already documented specification; however first I would like to
>> > confirm if I'm correct so far, or if I have missed something.
>> >
>> > TIA!
>> >
>> > --
>> > Janaka Bandara
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> >
>> >
>>
>
--
Janaka Bandara
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
