Gary, check out the mess I caused by not accepting your proposal for renaming "type" to "format": LOG4J2-2973 <https://issues.apache.org/jira/browse/LOG4J2-2973>. "type" conflicts with the array parsing semantics in properties file parser. Renaming "type" to "format" will allow us to read EventTemplateAdditionalField[] from properties files. While this is *not* a backward compatible change, injection of JSON template layout eventTemplateAdditionalFields has already been broken in release 2.14.0 and the introduced fix has already broken the backward compatibility. See LOG4J2-2961 <https://issues.apache.org/jira/browse/LOG4J2-2961> for details. Hence, it should be okay.
On Tue, Jul 14, 2020 at 11:59 PM 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 > > >>>> > > >> > > > > > > >
