Actually, I was thinking that we can keep the existing ObjectMapper but supply a Function that can “enhance” the ObjectMapper either at the end of the Log4jJsonObjectMapper constructor, at the end of JacksonFactory.newObjectMapper, or after the ObjectMapper is constructed in JacksonFactory.newWriter. Whether that is done via a Plugin or some other way I hadn’t looked at too much. But I suppose it could either be a Plugin that is a parameter to the Layout and then passed into the newWriter method or it could be looked up by the JSON method in JacksonFactory. Passing it on the Layout probably makes it more flexible.
Ralph > On Jul 12, 2019, at 4:13 PM, Carter Kozak <cko...@ckozak.net> wrote: > > I like the idea of an ObjectMapperFactory plugin point. That gives us a > cleaner builder API on JsonLayout where we can potentially pass in a supplier > for an ObjectMapper instance from programmatic configuration. > > On Fri, Jul 12, 2019, at 19:10, Matt Sicker wrote: >> And by plugin, see for example the various BlockingQueueFactory plugins. >> >> On Fri, Jul 12, 2019 at 18:09, Matt Sicker <boa...@gmail.com> wrote: >> >>> Plugin maybe? I think we could potentially extend the plugin system as a >>> general dependency and configuration injection system. We can make less >>> special case methods of pseudo components and options outside that. >>> >>> On Fri, Jul 12, 2019 at 17:34, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> Hi Dominik >>>> >>>> I see two ways of addressing this: >>>> 1) Add a setObjectMapper(ObjectMapper) >>>> to org.apache.logging.log4j.core.layout.JsonLayout.Builder >>>> This would work well for programmatic configurations >>>> and/or: >>>> 2) Add a setObjectMapperFactory(String) >>>> to org.apache.logging.log4j.core.layout.JsonLayout.Builder >>>> This would add a class name for implementors of a new interface >>>> ObjectMapperFactory. >>>> This would work nicely for configuration files. >>>> >>>> To keep all users in play, 2) seems best. >>>> >>>> Thoughts? >>>> >>>> Gary >>>> >>>> >>>> On Fri, Jul 12, 2019 at 8:38 AM Dominik Sandjaja < >>>> dominik.sandj...@trivago.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> we are using the JSON layout in our Spring Boot application to easily >>>>> ingest the logs in Elasticsearch. >>>>> >>>>> One message that we log is about failed conversions, when an incoming >>>>> request parameter cannot be converted correctly. As we use Spring’s >>>>> Converter functionality for this, these `IllegalArgumentException`s are >>>>> wrapped in a `ConversionFailedException`. This exception has fields of >>>> type >>>>> `TypeDescriptor` which hold information about the source and the target >>>>> type of the conversion. >>>>> >>>>> The problem is, that these `TypeDescriptor` objects cannot be serialized >>>>> to JSON. The simple call >>>>> >>>>> >>>>> >>>> com.fasterxml.jackson.databind.ObjectMapper().writeValueAsString(org.springframework.core.convert.TypeDescriptor.valueOf(String.javaClass)) >>>>> >>>>> throws an exception like >>>>> >>>>> ERROR StatusLogger >>>>> com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Direct >>>>> self-reference leading to cycle (through reference chain: >>>>> >>>> org.springframework.core.ResolvableType["componentType"]->org.springframework.core.ResolvableType["componentType"]) >>>>> com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Direct >>>>> self-reference leading to cycle (through reference chain: >>>>> >>>> org.springframework.core.ResolvableType["componentType"]->org.springframework.core.ResolvableType["componentType"]) >>>>> at >>>>> >>>> com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:77) >>>>> at >>>>> >>>> com.fasterxml.jackson.databind.SerializerProvider.reportBadDefinition(SerializerProvider.java:1191) >>>>> at >>>>> >>>> com.fasterxml.jackson.databind.ser.BeanPropertyWriter._handleSelfReference(BeanPropertyWriter.java:944) >>>>> at >>>>> >>>> com.fasterxml.jackson.databind.ser.BeanPropertyWriter.serializeAsField(BeanPropertyWriter.java:721) >>>>> at >>>>> >>>> com.fasterxml.jackson.databind.ser.std.BeanSerializerBase.serializeFields(BeanSerializerBase.java:719) >>>>> at >>>>> >>>> com.fasterxml.jackson.databind.ser.BeanSerializer.serialize(BeanSerializer.java:155) >>>>> >>>>> The error can be prevented if `Mixin`s are added to the `ObjectMapper` >>>>> which ignore the corresponding class. >>>>> >>>>> The `Log4jJsonObjectMapper` is initialized in the `JacksonFactory.JSON` >>>>> class and I currently do not see any way to somehow configure this >>>>> ObjectMapper with additional MixIns. >>>>> >>>>> Hence, my question finally is: >>>>> How can I configure Log4J’s JSON mapping to not break on such >>>>> non-serializable log content? >>>>> >>>>> Thank you! >>>>> Dominik >>>>> >>>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >> -- >> Matt Sicker <boa...@gmail.com> >> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
