You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Volkan Yazıcı <vo...@gmail.com> on 2020/07/14 12:51:26 UTC
Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
May I add a "type" (of type String) parameter to KeyValuePair? Do you
have any objections?
On Mon, Jul 6, 2020 at 8:01 AM Ralph Goers <ra...@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
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Gary Gregory <ga...@gmail.com>.
Hi Volkan,
I don't want to take the time to dig into the details but I am glad you
found a resolution. My main concern is for binary compatibility of our
call-site facing APIs, so breaking file formats is ok by me in this case.
Gary
On Thu, Jan 28, 2021, 05:59 Volkan Yazıcı <vo...@gmail.com> wrote:
> 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 <ga...@gmail.com>
> wrote:
>
> > On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers <ra...@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 <ga...@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.yazici@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 <
> garydgregory@gmail.com>
> > > >> wrote:
> > > >>>
> > > >>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <
> > volkan.yazici@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.goers@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
> > > >>>>
> > > >>
> > >
> > >
> > >
> >
>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Volkan Yazıcı <vo...@gmail.com>.
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 <ga...@gmail.com>
wrote:
> On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers <ra...@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 <ga...@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.yazici@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 <ga...@gmail.com>
> > >> wrote:
> > >>>
> > >>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <
> volkan.yazici@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.goers@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
> > >>>>
> > >>
> >
> >
> >
>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template
Layout)
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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 <ga...@gmail.com> wrote:
>>
>> On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers <ra...@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 <ga...@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ı <vo...@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 <ga...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <volkan.yazici@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.goers@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
>>>>>>>
>>>>>
>>>
>>>
>>>
>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template
Layout)
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ga...@gmail.com> wrote:
>
> On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers <ra...@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 <ga...@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ı <vo...@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 <ga...@gmail.com>
>>>> wrote:
>>>>>
>>>>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <volkan.yazici@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.goers@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
>>>>>>
>>>>
>>
>>
>>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers <ra...@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 <ga...@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ı <vo...@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 <ga...@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <volkan.yazici@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.goers@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
> >>>>
> >>
>
>
>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template
Layout)
Posted by Ralph Goers <ra...@dslextreme.com>.
Right now the type field in EventTemplateAdditionalField is an enum with possible values of JSON or STRING.
Ralph
> On Jul 14, 2020, at 7:43 AM, Gary Gregory <ga...@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ı <vo...@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 <ga...@gmail.com>
>> wrote:
>>>
>>> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <vo...@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.goers@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
>>>>
>>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Jul 15, 2020 at 10:06 AM Volkan Yazıcı <vo...@gmail.com> wrote:
>
> 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?
Would it work, to introduce a new GenericKeyValuePair<V>, and change
KeyValuePair to extend GenericKeyValuePair<String>?
Jochen
--
Look, that's why there's rules, understand? So that you think before
you break 'em.
-- (Terry Pratchett, Thief of Time)
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Volkan Yazıcı <vo...@gmail.com>.
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 <ga...@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ı <vo...@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 <ga...@gmail.com>
> > wrote:
> > >
> > > On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <vo...@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.goers@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
> > > >
> >
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Gary Gregory <ga...@gmail.com>.
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ı <vo...@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 <ga...@gmail.com>
> wrote:
> >
> > On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <vo...@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.goers@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
> > >
>
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Volkan Yazıcı <vo...@gmail.com>.
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 <ga...@gmail.com> wrote:
>
> On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <vo...@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 <ra...@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
> >
Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı <vo...@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 <ra...@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
>