Re: Json Template Layout event delimiter

[Volkan Yazıcı]

I had addressed this issue in 2020 July in a post titled "String parameter
with escapes (Was: Testing Json Template Layout)"
.
For one, *the issue is not specific to JTL*, but applies to almost every
layout accepting a parameter to be emitted along with the normal output.
Back then, the discussion focused on the null (\0) character needed by
SocketAppender for GELF layout in JTL. In the post, I suggested adding
something similar to `translateEscapes()` of Java 13. This would allow
users to pass escape characters with any string literal in any
configuration format; XML, YAML, properties, etc. Contrasting this with
your proposal for treating certain special inputs (e.g., "null", "Form
Feed") differently, for me, is not different than implementing a
`translateEscapes()`. I personally think this is even worse, since we
introduce a new syntax, whereas the former sticks to the standard Java
string syntax.

In conclusion, I propose adding a `translateEscapes()` clone and using that
to read `eventDelimiter` and deprecating `nullEventDelimiterEnabled`, since
`nullEventDelimiterEnabled` will simply translate to setting
`eventDelimiter` to `\0`. This breaks the backward compatibility of
`eventDelimiter`, since there might be users out there who set their
`eventDelimiter` to `\t\r\n` and was expecting to get that string literal
as is. Yet, given the relatively recent introduction of the plugin, I think
we can take this risk.

On Mon, Sep 13, 2021 at 6:14 AM Ralph Goers 
wrote:

> I have been working on getting a configuration that works with filebeat
> going again and have been
> trying to change the line delimiter so I could avoid doing the multiline
> crap. I first configured
> eventDelimiter=“\f” since filebeat supports that as a replacement for
> newline. Except no matter
> how hard I tried I couldn’t get filebeat to log anything to stdout.
>
> I spent hours looking at it before I finally realized that the logs being
> written actually had “\f” in
> the string instead of a form feed character. It seems that XML must be
> passing in the value
> treating the “\” as if it is escaped.  To remedy this the only solution I
> could come up with was
>
>  locationInfoEnabled="true">
>   …
> 
> It seems that XML doesn’t allow a form feed character specified that way.
> This caused filebeat
> to start recognizing the log events.  I would suggest that we may want to
> change eventDelimiter
> to accept enum names instead of or in addition to characters, which is
> what filebeat does. So
> one could specify eventDelimiter=“Form Feed”.
>
> Ralph

[log4cxx] Do a 12.1 release?

[Robert Middleton]

Without the fix for LOGCXX-534, multithreaded rolling logging is
broken.  Since it's  a pretty simple and minor fix, I was thinking
that we should do a release with just this fix, as this seems like it
could be a common configuration.  Thoughts?

-Robert Middleton

Re: [log4cxx] Do a 12.1 release?

[Thorsten Schöning]

Guten Tag Robert Middleton,
am Montag, 13. September 2021 um 15:24 schrieben Sie:

> Without the fix for LOGCXX-534, multithreaded rolling logging is
> broken.  Since it's  a pretty simple and minor fix, I was thinking
> that we should do a release with just this fix, as this seems like it
> could be a common configuration.  Thoughts?

Sounds reasonable to me, especially when looking at the signalling
stuff. Who knows what that might break, so +1 here.

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: thorsten.schoen...@am-soft.de
Web:http://www.AM-SoFT.de/

Tel:   05151-  9468- 0
Tel:   05151-  9468-55
Fax:   05151-  9468-88
Mobil:  0178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska

Re: Json Template Layout event delimiter

[Apache]

I don’t think anyone passing an escape sequence expects it to show up as a 
string. So I would be good with your proposed solution. That method should be 
part of core so we can modify all Layouts to use it.

Ralph

> On Sep 13, 2021, at 12:29 AM, Volkan Yazıcı  wrote:
> 
> I had addressed this issue in 2020 July in a post titled "String parameter
> with escapes (Was: Testing Json Template Layout)"
> .
> For one, *the issue is not specific to JTL*, but applies to almost every
> layout accepting a parameter to be emitted along with the normal output.
> Back then, the discussion focused on the null (\0) character needed by
> SocketAppender for GELF layout in JTL. In the post, I suggested adding
> something similar to `translateEscapes()` of Java 13. This would allow
> users to pass escape characters with any string literal in any
> configuration format; XML, YAML, properties, etc. Contrasting this with
> your proposal for treating certain special inputs (e.g., "null", "Form
> Feed") differently, for me, is not different than implementing a
> `translateEscapes()`. I personally think this is even worse, since we
> introduce a new syntax, whereas the former sticks to the standard Java
> string syntax.
> 
> In conclusion, I propose adding a `translateEscapes()` clone and using that
> to read `eventDelimiter` and deprecating `nullEventDelimiterEnabled`, since
> `nullEventDelimiterEnabled` will simply translate to setting
> `eventDelimiter` to `\0`. This breaks the backward compatibility of
> `eventDelimiter`, since there might be users out there who set their
> `eventDelimiter` to `\t\r\n` and was expecting to get that string literal
> as is. Yet, given the relatively recent introduction of the plugin, I think
> we can take this risk.
> 
>> On Mon, Sep 13, 2021 at 6:14 AM Ralph Goers 
>> wrote:
>> 
>> I have been working on getting a configuration that works with filebeat
>> going again and have been
>> trying to change the line delimiter so I could avoid doing the multiline
>> crap. I first configured
>> eventDelimiter=“\f” since filebeat supports that as a replacement for
>> newline. Except no matter
>> how hard I tried I couldn’t get filebeat to log anything to stdout.
>> 
>> I spent hours looking at it before I finally realized that the logs being
>> written actually had “\f” in
>> the string instead of a form feed character. It seems that XML must be
>> passing in the value
>> treating the “\” as if it is escaped.  To remedy this the only solution I
>> could come up with was
>> 
>> > locationInfoEnabled="true">
>>  …
>> 
>> It seems that XML doesn’t allow a form feed character specified that way.
>> This caused filebeat
>> to start recognizing the log events.  I would suggest that we may want to
>> change eventDelimiter
>> to accept enum names instead of or in addition to characters, which is
>> what filebeat does. So
>> one could specify eventDelimiter=“Form Feed”.
>> 
>> Ralph

Re: Json Template Layout event delimiter

[Ralph Goers]

I just looked at the stack overflow post you referenced. Although the author is 
explicitly 
giving permission for everyone to use it everything at StackOverflow is 
licensed as 
CC-By 4.0. That is covered at https://www.apache.org/legal/resolved.html#cc-by 
.

It would be best if you could reach out to the author and ask him to post the 
code 
on GitHub or directly give it to you and bypass StackOverflow. If he posts it 
to GitHub 
he should include a License.txt with whatever license he wants to use. 
Hopefully 
something like MIT or Apache.

Ralph

> On Sep 13, 2021, at 7:08 AM, Apache  wrote:
> 
> I don’t think anyone passing an escape sequence expects it to show up as a 
> string. So I would be good with your proposed solution. That method should be 
> part of core so we can modify all Layouts to use it.
> 
> Ralph
> 
>> On Sep 13, 2021, at 12:29 AM, Volkan Yazıcı  wrote:
>> 
>> I had addressed this issue in 2020 July in a post titled "String parameter
>> with escapes (Was: Testing Json Template Layout)"
>> .
>> For one, *the issue is not specific to JTL*, but applies to almost every
>> layout accepting a parameter to be emitted along with the normal output.
>> Back then, the discussion focused on the null (\0) character needed by
>> SocketAppender for GELF layout in JTL. In the post, I suggested adding
>> something similar to `translateEscapes()` of Java 13. This would allow
>> users to pass escape characters with any string literal in any
>> configuration format; XML, YAML, properties, etc. Contrasting this with
>> your proposal for treating certain special inputs (e.g., "null", "Form
>> Feed") differently, for me, is not different than implementing a
>> `translateEscapes()`. I personally think this is even worse, since we
>> introduce a new syntax, whereas the former sticks to the standard Java
>> string syntax.
>> 
>> In conclusion, I propose adding a `translateEscapes()` clone and using that
>> to read `eventDelimiter` and deprecating `nullEventDelimiterEnabled`, since
>> `nullEventDelimiterEnabled` will simply translate to setting
>> `eventDelimiter` to `\0`. This breaks the backward compatibility of
>> `eventDelimiter`, since there might be users out there who set their
>> `eventDelimiter` to `\t\r\n` and was expecting to get that string literal
>> as is. Yet, given the relatively recent introduction of the plugin, I think
>> we can take this risk.
>> 
>>> On Mon, Sep 13, 2021 at 6:14 AM Ralph Goers 
>>> wrote:
>>> 
>>> I have been working on getting a configuration that works with filebeat
>>> going again and have been
>>> trying to change the line delimiter so I could avoid doing the multiline
>>> crap. I first configured
>>> eventDelimiter=“\f” since filebeat supports that as a replacement for
>>> newline. Except no matter
>>> how hard I tried I couldn’t get filebeat to log anything to stdout.
>>> 
>>> I spent hours looking at it before I finally realized that the logs being
>>> written actually had “\f” in
>>> the string instead of a form feed character. It seems that XML must be
>>> passing in the value
>>> treating the “\” as if it is escaped.  To remedy this the only solution I
>>> could come up with was
>>> 
>>> >> locationInfoEnabled="true">
>>> …
>>> 
>>> It seems that XML doesn’t allow a form feed character specified that way.
>>> This caused filebeat
>>> to start recognizing the log events.  I would suggest that we may want to
>>> change eventDelimiter
>>> to accept enum names instead of or in addition to characters, which is
>>> what filebeat does. So
>>> one could specify eventDelimiter=“Form Feed”.
>>> 
>>> Ralph
> 
> 
> 

PR Build Failures

[Carter Kozak]

Hi all,

Does anyone know why our PR builds recently began to fail posting status after 
successfully running the build?

> Posting status 'completed' with conclusion 'success' to 
> https://github.com/apache/logging-log4j2/pull/579 (sha:
> 782a2769bdcd30e5f913b900fff59aa6250db53b)
> Error: Resource not accessible by integration

Probably something simple, asking here before I spend time debugging it :-)

Thanks,
Carter

Missing commits on the master branch

[Carter Kozak]

In cherry-picking a change from release-2.x to master I ran into some conflicts 
because 
https://github.com/apache/logging-log4j2/commit/97ec707d69280ef57aed8fd5831dc4f3a75f7715
 was merged to the release branch, but never ported to master. Gary, do you 
recall if this was intentional? If not I'd be more than happy to handle the 
cherry-pick for you.

Before we release a 3.x from master we should probably do an audit for this 
sort of change, httpcomponents had a long-lived 5.x branch which received 
several malformed cherry-pick resolutions which ultimately had some negative 
impact in our production environments (They were relatively minor and easy 
enough to fix once they were found, just something we should be aware of). I 
want to make sure we we avoid this sort of bug to the extent possible.

Best,
Carter

Re: [log4cxx] Do a 12.1 release?

[Robert Middleton]

I'll do a release sometime in the next week or two then,
cherry-picking that one commit.  It shouldn't be that hard to do.

-Robert Middleton

On Mon, Sep 13, 2021 at 10:00 AM Thorsten Schöning
 wrote:
>
> Guten Tag Robert Middleton,
> am Montag, 13. September 2021 um 15:24 schrieben Sie:
>
> > Without the fix for LOGCXX-534, multithreaded rolling logging is
> > broken.  Since it's  a pretty simple and minor fix, I was thinking
> > that we should do a release with just this fix, as this seems like it
> > could be a common configuration.  Thoughts?
>
> Sounds reasonable to me, especially when looking at the signalling
> stuff. Who knows what that might break, so +1 here.
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   05151-  9468- 0
> Tel:   05151-  9468-55
> Fax:   05151-  9468-88
> Mobil:  0178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
>
>

Re: Missing commits on the master branch

[Gary Gregory]

I must have gotten side tracked and not ported to master. Sorry about that.
Please go ahead, on planes today...

Gary

On Mon, Sep 13, 2021, 13:59 Carter Kozak  wrote:

> In cherry-picking a change from release-2.x to master I ran into some
> conflicts because
> https://github.com/apache/logging-log4j2/commit/97ec707d69280ef57aed8fd5831dc4f3a75f7715
> was merged to the release branch, but never ported to master. Gary, do you
> recall if this was intentional? If not I'd be more than happy to handle the
> cherry-pick for you.
>
> Before we release a 3.x from master we should probably do an audit for
> this sort of change, httpcomponents had a long-lived 5.x branch which
> received several malformed cherry-pick resolutions which ultimately had
> some negative impact in our production environments (They were relatively
> minor and easy enough to fix once they were found, just something we should
> be aware of). I want to make sure we we avoid this sort of bug to the
> extent possible.
>
> Best,
> Carter
>

Re: PR Build Failures

[Gary Gregory]

I've not seen this type of error before, looks like something went wrong
with jubit reports.

Gary

On Mon, Sep 13, 2021, 13:38 Carter Kozak  wrote:

> Hi all,
>
> Does anyone know why our PR builds recently began to fail posting status
> after successfully running the build?
>
> > Posting status 'completed' with conclusion 'success' to
> https://github.com/apache/logging-log4j2/pull/579 (sha:
> > 782a2769bdcd30e5f913b900fff59aa6250db53b)
> > Error: Resource not accessible by integration
>
> Probably something simple, asking here before I spend time debugging it :-)
>
> Thanks,
> Carter
>