Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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ı wrote: > Gary,

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

Gary, check out the mess I caused by not accepting your proposal for renaming "type" to "format": LOG4J2-2973 . "type" conflicts with the array parsing semantics in properties file parser. Renaming "type" to "format" will allow us to read

Re: Testing Json Template Layout

Yes, please do. Ralph > On Jul 22, 2020, at 6:22 AM, Volkan Yazıcı wrote: > > Ralph, I am fine with the current state of the plugin. I don't intend to > have further improvements in the short-term regarding KeyValuePair > enhancements and/or escape character handling. If you are okay with it,

Re: Testing Json Template Layout

Ralph, I am fine with the current state of the plugin. I don't intend to have further improvements in the short-term regarding KeyValuePair enhancements and/or escape character handling. If you are okay with it, I want to start rebasing this onto 2.x branch. On Mon, Jul 6, 2020 at 8:01 AM Ralph

Re: String parameter with escapes (Was: Testing Json Template Layout)

We can’t “backport” the code from Java 13 as that is licensed under the GPL. What I was suggesting (without saying it) was that maybe we don’t need the eventDelimiter parameter. Yes, this should be solved across the board so everything is consistent. Ralph > On Jul 15, 2020, at 12:53 AM,

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

On Wed, Jul 15, 2020 at 10:06 AM Volkan Yazıcı 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` -- `KeyValuePair` feels like > an engineering overkill for our

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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` -- `KeyValuePair` feels like an engineering overkill for our usages. That said, this translates to 368 occurrences of

Re: String parameter with escapes (Was: Testing Json Template Layout)

First let me state that this "how to pass escape characters to plugin parameters of type string from different configuration sources" problem applies to every other plugin, e.g., `AbstractJacksonLayout.Builder#endOfLine`. Hence, nothing specific to `JsonTemplateLayout`. That said, I share your

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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 wrote: > > On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers > wrote: > >> Right now the type field in

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

On Tue, Jul 14, 2020 at 1:55 PM Ralph Goers 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"

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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 wrote: > > Hi All, > > There are three types of solutions I see to these kinds of wants, depending > of what the domain of the 'type'

Re: String parameter with escapes (Was: Testing Json Template Layout)

Do we really need to do this? The only two delimiters that have ever been requested are null and newline. Defaulting to newline and having an option to use null seems fine to me. Ralph > On Jul 14, 2020, at 5:49 AM, Volkan Yazıcı wrote: > > Thinking more on this issue made me question the

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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 or KeyValuePair and/or - Add a Class instance variable to denote the type, the hack usually reserved to workaround type erasure, or - Add

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

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 wrote: > > On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı > wrote: > > > May I add a "type" (of type String) parameter to KeyValuePair? Do you > > have any

Re: Adding type attribute to KeyValuePair (Was: Testing Json Template Layout)

On Tue, Jul 14, 2020 at 8:51 AM Volkan Yazıcı 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 > wrote: > > > > I finally got some time to start

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

String parameter with escapes (Was: Testing Json Template Layout)

Thinking more on this issue made me question the ideal way to pass Java string literals to plugins. I first gave Matt's suggestion a try, set eventDelimiter="" in the XML and got the following error: ERROR StatusLogger Error parsing /home/vy/...Logging.xml org.xml.sax.SAXParseException;

Re: Testing Json Template Layout

Maybe. But it isn’t obvious and would have to be explicitly documented. Ralph > On Jul 12, 2020, at 8:09 AM, Matt Sicker wrote: > > Wouldn’t that be in XML? > > On Sat, Jul 11, 2020 at 16:26 Ralph Goers > wrote: > >> I guess what you mean is that where you have $resolver: “message” that >>

Re: Testing Json Template Layout

Wouldn’t that be in XML? On Sat, Jul 11, 2020 at 16:26 Ralph Goers wrote: > I guess what you mean is that where you have $resolver: “message” that > would somehow be replaced by $resolver” “pattern”? That would make sense. > I have no problem with the changes you are suggesting. However, you

Re: Testing Json Template Layout

I guess what you mean is that where you have $resolver: “message” that would somehow be replaced by $resolver” “pattern”? That would make sense. I have no problem with the changes you are suggesting. However, you should also change the configuration shown in cloud.md and the log4j2.xml in

Re: Testing Json Template Layout

I can't believe how were we expecting somebody to pass a null character from an XML file! Long story short, it was the XML parser, doing the right thing, that is, converting XML attribute value "\0" to Java String "\\0". Okay, I am not gonna whine about this anymore. I have just pushed a commit

Re: Testing Json Template Layout

Reading your changes again, I think your `MessageResolver` improvements are a clone of `PatternResolver`. Hence, I will revert the `MessageResolver` changes. Objections? (Sorry that it took awhile for me to get it clicked. Saturday evening...) On Sat, Jul 11, 2020 at 8:37 PM Volkan Yazıcı

Re: Testing Json Template Layout

Hello Ralph! Sorry that it took me this long to reply to you back in detail, but I have just found time to do so. Let me try to address the points you raised: > 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

Re: Testing Json Template Layout

A couple other things. As I was implementing stuff I noticed you implemented stuff using lots of static methods. I am not really sure why since almost all of those methods are only invoked from an instance of the object. I had to change that to get my enhancements to work. Also, I would like

Re: Testing Json Template Layout

Hey Ralph, Thanks so much for taking time, really appreciated. Unfortunately the last few days I was pretty busy both at home and at work. I will check out your changes and reply back as soon as I find some time. Kind regards. On Wed, Jul 8, 2020 at 1:08 AM Ralph Goers wrote: > > Volkan, > > I

Re: Testing Json Template Layout

Volkan, I have updated the relevant documentation. I am done with all the changes I wanted to make. Ralph > On Jul 6, 2020, at 2:50 PM, Ralph Goers wrote: > > I have fixed the issue with the annotations. I have added the ability to > format the message field using a pattern and I have

Re: Testing Json Template Layout

I have fixed the issue with the annotations. I have added the ability to format the message field using a pattern and I have modified the code so that specifying eventDelimiter=“null” will insert a null at the end of the message as specifying eventDelimiter=“\0” or “\u000” does not work (It

Testing Json Template Layout

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