The reason I wanted to go with a simple `String type` field is to keep the impact surface and backward compatibility issues at the bay.
I am in favor of `KeyValuePair<V>` -- `KeyValuePair<K,V>` feels like an engineering overkill for our usages. That said, this translates to 368 occurrences of `KeyValuePair` in the code that needs to be adjusted. Do we really want to go in that direction? On Tue, Jul 14, 2020 at 4:44 PM 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 > > > > > >
