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 >>>>>> >>>> >> >> >>
