Open
Description
When the Log4j LogEvent
context data contains non string values e.g string arrays or java maps, the resulting attributes are incorrect.
Create a class extending ObjectThreadContextMap
and set it as the default using the log4j system property log4j2.threadContextMap
Add the following code:
public class MyObjectContextMap implements ReadOnlyThreadContextMap, ObjectThreadContextMap {
//Implementation methods
}
In the logging code add the following
MyObjectContextMap map = (MyObjectContextMap)ThreadContext.getThreadContextMap();
map.putValue("numbers", new String[]{"one", "two", "three"});
HashMap testmap = new HashMap();
testmap.put("fn", "firstname");
testmap.put("ln", "lastname");
testmap.put(age, 25);
map.put("testmap", testmap);
logger.log(Level.TRACE, "test message");
What did you expect to see?
I would expect that the nested value and the array value would be included in attributes properly.
What did you see instead?
I saw the .toString()
representations of the array and map. So numbers
showed as an attribute with value [Ljava.lang.String
and testmap
showed up as a single value with the map values as {fn=firstname, ln=lastname}
.
What version are you using?
1.23.0-alpha
Log4j: 2.17.1
Activity
breedx-splk commentedon Jul 11, 2023
The root cause might be this? https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/log4j/log4j-appender-2.17/library/src/main/java/io/opentelemetry/instrumentation/log4j/appender/v2_17/internal/LogEventMapper.java#L163
It doesn't really look like the current design is intended to handle heterogeneous types, especially list/collection types.
This test can be added to the
LogEventMapperTest
to verify the behavior:Open to ideas.
zeitlinger commentedon Jul 12, 2023
What about flattening maps (unless they are pat of an array)?
testmap.fn = firstname
testmap.numbers = one, two, three
mateuszrzeszutek commentedon Jul 13, 2023
I think that nested attributes (open-telemetry/opentelemetry-specification#2888) would probably be something we'd want to use here; they're not specced yet though.
trask commentedon Aug 15, 2023
👍
any thoughts what to do in the meantime?
skipping them is probably better from a stability perspective if we are hoping to use nested attributes in the future
mateuszrzeszutek commentedon Aug 16, 2023
Agree on skipping them 👍
Let's wait for the decision on nested attributes.
fandreuz commentedon Apr 30, 2025
I believe this is now being addressed by open-telemetry/opentelemetry-specification#4485, can I work on this issue?
trask commentedon Apr 30, 2025
hi @fandreuz, that would be great! Since this is on the log signal, I don't think you need to wait for open-telemetry/opentelemetry-specification#4485, but you probably will need to wait for the next Java release which will have experimental support for complex attributes on logs: open-telemetry/opentelemetry-java#7123
ExtendedAttributes
API open-telemetry/opentelemetry-java#7323