What is the purpose of disabling ThrowableProxy? All the throwable pattern
converters rely on it.
Ralph
> On Aug 8, 2018, at 8:34 AM, Carter Kozak wrote:
>
> I'm curious what you would think of a system property to disable
> ThrowableProxy creation?
> My initial preference was to avoid this ty
Yup. Part of the problem is that StackWalker is optimized for only walking a
few frames. I think it caches 8 stack frames. After that it apparently slows
down a lot. I don’t recall there being any way to tune that.
Ralph
> On Aug 8, 2018, at 5:07 PM, Remko Popma wrote:
>
> What I remember fro
What I remember from email interactions that Ralph had with the people working
on the Stackwalker implementation:
Ostensibly Stackwalker was supposed to give performance benefits for use cases
like ours. They even mentioned discovering the location of a logging call as
one of the main use cases
Hi all,
I just went ahead and filed an initial PR here:
https://github.com/apache/logging-log4j2/pull/206. No copying from GPL code
involved! I'd be happy to make any changes needed to merge.
Thanks,
Kevin
On Tue, Aug 7, 2018 at 1:51 PM, Gary Gregory wrote:
> IOW, think clean room.
>
> G
>
>
StackWalker seems to be implemented purely as it says: walking the call
stack. If all you need is the stack of classes (e.g., for checking runtime
permissions based on the calling class), then the SecurityManager makes
most sense since it seems built for that exact purpose. I'd imagine there
are op
I'm curious what you would think of a system property to disable
ThrowableProxy creation?
My initial preference was to avoid this type of flag and make the
common case cleaner, however
without providing a mechanism to disable the functionality that
differentiates it from Throwable
I'm not sure that
