Did you create a Jira issue for this? One of us might get around to it but we never will without the Jira issue reminding us.
Ralph > On Jul 16, 2019, at 8:12 AM, Dominik Sandjaja <dominik.sandj...@trivago.com> > wrote: > > Hello everybody, > > thank you all for the discussion about this topic. > > My initial thought was that I was maybe missing some configuration option for > setting the classname of one of the initialization classes to override the > object creation. > But after looking a bit into the Log4J Plugin system I agree, that this is > the cleanest way forward from an overall architectural point of view. > > I don't think that I will be able to provide a Pull Request within the next > few weeks (hooray for holidays!), but if time permits, I could have a shot at > it in September. > > Until then, we will most likely remove this one exception from the Exception > chain. > > Thank you all! > > On 13.07.19, 22:34, "Matt Sicker" <boa...@gmail.com> wrote: > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
