FWIW, this is one area Log4j could use improvement as the way it is done is too brittle. Ideally the Layout should be able to specify the format for all messages to use in a generic way. I don’t believe that is the case today. I am also sure user’s would like to be able to customize that to some degree.
Ralph > On Jul 14, 2020, at 3:44 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > That is true. There is at least one other place where we use “format” to > differentiate between JSON, XML, and Java. See MapMessage. > > Ralph > >> On Jul 14, 2020, at 11:06 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> Right now the type field in EventTemplateAdditionalField is an enum with >>> possible values of JSON or STRING. >>> >> >> This feels misnamed to me, JSON vs STRING is not a "type", JSON is a >> "format", as in JSON vs. XML, and STRING could be a "type" only in the >> free-form-string sense (to my mind again.) >> So maybe this is a "format" choice of JSON vs. ANY_STRING/ >> >> 2c, >> Gary >> >> >>> Ralph >>> >>>> On Jul 14, 2020, at 7:43 AM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>>> >>>> Hi All, >>>> >>>> There are three types of solutions I see to these kinds of wants, >>> depending >>>> of what the domain of the 'type' is: >>>> - KeyValuePair -> KeyValuePair<K,V> or KeyValuePair<V> and/or >>>> - Add a Class<?> instance variable to denote the type, the hack usually >>>> reserved to workaround type erasure, or >>>> - Add something else like a String type ivar, which is what? A free-form >>>> string? >>>> >>>> Gary >>>> >>>> On Tue, Jul 14, 2020 at 10:24 AM Volkan Yazıcı <volkan.yaz...@gmail.com> >>>> wrote: >>>> >>>>> Adding a "String type" field sounds pretty generic to me. What do you >>>>> mean by "generic"? >>>>> >>>>> On Tue, Jul 14, 2020 at 4:10 PM Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>>> >>>>>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <volkan.yaz...@gmail.com >>>> >>>>>> wrote: >>>>>> >>>>>>> May I add a "type" (of type String) parameter to KeyValuePair? Do you >>>>>>> have any objections? >>>>>>> >>>>>> >>>>>> Would we want to make this a generic? >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>>> >>>>>>> On Mon, Jul 6, 2020 at 8:01 AM Ralph Goers < >>> ralph.go...@dslextreme.com >>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> I finally got some time to start testing JsonTemplateLayout against >>>>> the >>>>>>> logging in the cloud documentation. The first problem I ran into is >>>>> that >>>>>>> additional fields don’t work. I don’t see any configurations that have >>>>> them >>>>>>> and the Builder doesn’t have annotations on the key and value fields >>>>> so I >>>>>>> suspect it just doesn’t work. Why didn’t you just enhance >>>>> KeyValuePair to >>>>>>> add the type attribute? >>>>>>>> >>>>>>>> After I corrected the EventTemplateAdditionalField plugin I still >>>>> can’t >>>>>>> get stack traces the way I want them. I thought you said you added the >>>>>>> ability to format the message using a pattern, but I don’t see that in >>>>> the >>>>>>> documentation or in MessageResolver. Was that not included? As I said, >>>>> I >>>>>>> require the stack trace to print in the message field in Kibana, not >>>>> just >>>>>>> be a key in the additional data. >>>>>>>> >>>>>>>> >>>>>>>> Ralph >>>>>>> >>>>> >>> >>> >>> >
