Open Zack-Freedman-Thoughtworks opened 3 months ago
When I first noticed this issue, the error presented as a JsonMappingException
which is likely related to using JsonLayout
Yes, this is really something related to the specific log4j impl. I don't have a good idea how to fix that (looking for {} placeholder in strings feels an overkill, as anyway we will just throw an exception).
Is there any workaround for this or should we stay away from the version upgrade? I'd like to avoid breaking some logs for an upgrade.
I am not sure what you're trying to upgrade: from which version to which and how does the log call changes. I suspect using a payload is what causing this, so I expect that change to be breaking anyway, and need to be tested.
Can you please provide so more details?
Hi, as you guessed, we were experimenting with a major version increment where we weren't using payloads in the past. I suppose we can still upgrade as long as we don't allow payloads, but that seems hard to enforce.
In the following example, the first error leads to the failure:
Configuration:
It doesn't seem like the issue happens with Spring Boots default logger
spring-boot-starter-logging
(vs log4j2).I am aware this is an error arising from log4j but I'm wondering if there is something we can do for these methods to always avoid parameterized messaging. As far as I understand, we couldn't use
atInfo
to parameterize messages anyways.Example can be found here. Let me know if there's a better way to provide examples.