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