Being a plugin means you can inject it as a @PluginElement wherever. Plus, that makes it easier for users to write a custom plugin class to configure any other options they want. Comparable to the DataSourceFactory or whatever it’s called for JDBC drivers in that plugin.
Keeping it as an element should make it more flexible with future programmatic configuration ideas. The more component based everything is, the simpler it’ll be to make customizations without users digging into the internals of LoggerConfig et al. On Fri, Jul 12, 2019 at 18:36, Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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 > > -- Matt Sicker <boa...@gmail.com>
