Oh, that's a part of the plugin system I often forget about since most plugins are core plugins. In any case, a plugin of some sort would be the most flexible here I think.
On Sat, 13 Jul 2019 at 15:21, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Just because it is a plugin doesn’t mean it can be used anywhere. The > JacksonFactory could collect plugins for its own category, which would mean > they couldn’t be specified in the configuration. Only “core” plugins can > directly be used as parameters in the configuration. But yes, once it is a > core plugin it could be passed into the newWriter method as I describe. > > Ralph > > > On Jul 13, 2019, at 10:12 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > 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> > > > > --------------------------------------------------------------------- > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
