Re: Unable to locate plugin type for Custom log4j2 Appender

[Volkan Yazıcı]

Hello Amanda,

See my comments inline below.

On Tue, 6 Aug 2024 at 01:05, Amanda Liu  wrote:
> The reason I want a custom appender is to pretty print the JSON log
> objects produced by JsonTemplateLayout, to make it more readable.

Would you mind giving us a little bit more context, please? Why do you need
the JSON output to be readable?

> Is there any strong reason why JsonTemplateLayout does
> not support JSON pretty print?

Yes, efficiency – both from computation and bandwidth usage perspectives.
Plus, JTL output is not intended to be consumed by humans, but machines.
The recommended practice is to contain multiple logging configurations for
different use cases. That is, while developing locally, you can choose a
layout producing a more human-readable output, e.g., Pattern Layout. At
production, you can switch to JTL. You can implement such an
environment-specific Log4j configuration either using your framework
best-practices (e.g., Spring Boot has excellent support for these kinds of
scenarios) or Log4j itself (e.g., using arbiters). To guide you on choosing
the right solution, we need to know more about your context: Which
framework do you use? How do you deploy your application? etc.

> This would resolve my issue, and I think other log4j
> JsonTemplateLayout users may be interested in the pretty print feature.

I am not keen on adding such a feature without a use case, of which we
haven't been told so far.

On Tue, Aug 13, 2024 at 8:52 PM Piotr P. Karwasz 
wrote:

> Hi Amanda,
>
> I am crossposting this to dev@logging.apache.org. Please answer to
> that mailing list.
>
> On Tue, 6 Aug 2024 at 01:05, Amanda Liu  wrote:
> > The reason I want a custom appender is to pretty print the JSON log
> objects produced by JsonTemplateLayout, to make it more readable. I see in
> the log4j docs that JSON pretty print is supported in JsonLayout, but not
> JsonTemplateLayout. I don't want to use JsonLayout, since it's deprecated
> and doesn't support some other features that JSONTemplateLayout has.
> >
> > Is there any strong reason why JsonTemplateLayout does not support JSON
> pretty print? Or could I contribute to the JsonTemplateLayout file in the
> log4j repo to add this feature? (here:
> https://github.com/apache/logging-log4j2/blob/a884e991c1a551cb321b2efed770a15fbc55aa2b/log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/JsonTemplateLayout.java).
> This would resolve my issue, and I think other log4j JsonTemplateLayout
> users may be interested in the pretty print feature.
>
> There is no special reason why `JsonTemplateLayout` does not support
> pretty print. It was simply never implemented.
>
> Currently JTL only writes to a small `JsonWriter`[1] class through
> `TemplateResolver.resolve()`[2]. This could be easily generalized
> (probably in `3.x`) by replacing `JsonWriter` with an interface, to
> support multiple serialization formats. There is already a JIRA issue
> for that (see LOG4J2-3082[0]).
>
> Admittedly this requires quite some work, but it is within the grasp
> of a semester-long student project or Google Summer of Code.
>
> If you are willing to contribute such a feature, we can always assist
> you with the Log4j-related details.
>
> Piotr
>
> BTW: I added more info about shading applications that use Log4j Core
> to our documentation[3]
>
> [0] https://issues.apache.org/jira/browse/LOG4J2-3082
> [1]
> https://javadoc.io/static/org.apache.logging.log4j/log4j-layout-template-json/2.19.0/org/apache/logging/log4j/layout/template/json/util/JsonWriter.html
> [2]
> https://javadoc.io/static/org.apache.logging.log4j/log4j-layout-template-json/2.19.0/org/apache/logging/log4j/layout/template/json/resolver/TemplateResolver.html#resolve-V-org.apache.logging.log4j.layout.template.json.util.JsonWriter-
> [3]
> https://github.com/apache/logging-log4j2/blob/2.x/src/site/antora/modules/ROOT/pages/faq.adoc#how-do-i-create-a-single-jar-application-containing-log4j-core
>

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Piotr P. Karwasz]

Hi Gary,

On Fri, 9 Aug 2024 at 12:15, Gary Gregory  wrote:
> While it is a different community, I have received negative feedback in
> Commons against the trend to spread information all over the place, and we
> don't use GitHub.
>
> The TLDR is that in the past it was easier to find information because you
> only had the mailing list and later Jira. Now you have multiple mailing
> lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus
> Slack. Adding to the list is GitHub issues...

Might I propose a split of concerns between GH Discussions and the
mailing lists:

* We use GH Discussions as a replacement for `log4j-user`,
`log4net-user`, `log4cxx-user`. Two of these mailing lists are dead
anyway, since subscribing to a ML for a one-off question is a hustle.
* We use `dev@logging` as always for reaching consensus and decisions
concerning the directions we choose for development.

BTW: Can we deactivate all the mailing lists except `dev`, `private`
and `security`?

Piotr

Re: Unable to locate plugin type for Custom log4j2 Appender

[Volkan Yazıcı]

Thanks for bringing this to our attention, Piotr.

[See my comments inline below.]

On Tue, Aug 13, 2024 at 8:52 PM Piotr P. Karwasz 
wrote:

> There is no special reason why `JsonTemplateLayout` does not support
> pretty print. It was simply never implemented.
>

See my response to Amanda
, there
are good reasons for not doing it. For one, we first need to start with
answering "Why shall we do it?". If we hear a compelling use case, it is
still technically not trivial due to `JsonWriter#writeRawString()` methods.
Putting that detail aside, I am in favor of guiding users to choose the
right tool for the right job, instead of trying to make every tool cater
for all jobs.


> This could be easily generalized
> (probably in `3.x`) by replacing `JsonWriter` with an interface, to
> support multiple serialization formats. There is already a JIRA issue
> for that (see LOG4J2-3082[0]).
>

Making `JsonWriter` pluggable can indeed be a nice feature. It can even be
served in Log4j 2 without breaking backward compatibility. But it is a
pretty big undertaking. My suggestion is to implement a small enhancement
that is simpler: falling back to an external serializer (e.g., Jackson) for
unknown types. We can easily ship this in Log4j 2 and it addresses the use
case stated in LOG4J2-3082
.


> Admittedly this requires quite some work, but it is within the grasp
> of a semester-long student project or Google Summer of Code.


> If you are willing to contribute such a feature, we can always assist
> you with the Log4j-related details.
>

I am not inclined to support pretty-printing in JTL, but I would
completely support an initiative for enhancing `JsonWriter` with a fallback
serializer to address LOG4J2-3082.

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Gary Gregory]

I think that to "deactivate" the mailing lists you refer to would be very
bad and might not even be allowed by Apache.

You cannot/shouldn't force people to create a GitHub (Microsoft) account
just to talk to us.

Odd as it sounds, I've had someone told me they would not submit a PR
because they did not want to create a GH account. It feels
counterproductive from my POV not to submit PRs but it shouldn't lock
people out.

There might also be parts of the world where GH is not available but Apache
servers are (more of a geopolitical issue).

Gary

On Wed, Aug 14, 2024, 3:43 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Fri, 9 Aug 2024 at 12:15, Gary Gregory  wrote:
> > While it is a different community, I have received negative feedback in
> > Commons against the trend to spread information all over the place, and
> we
> > don't use GitHub.
> >
> > The TLDR is that in the past it was easier to find information because
> you
> > only had the mailing list and later Jira. Now you have multiple mailing
> > lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus
> > Slack. Adding to the list is GitHub issues...
>
> Might I propose a split of concerns between GH Discussions and the
> mailing lists:
>
> * We use GH Discussions as a replacement for `log4j-user`,
> `log4net-user`, `log4cxx-user`. Two of these mailing lists are dead
> anyway, since subscribing to a ML for a one-off question is a hustle.
> * We use `dev@logging` as always for reaching consensus and decisions
> concerning the directions we choose for development.
>
> BTW: Can we deactivate all the mailing lists except `dev`, `private`
> and `security`?
>
> Piotr
>

Re: Unable to locate plugin type for Custom log4j2 Appender

[Piotr P. Karwasz]

Hi Volkan,

[I am dropping `log4j-user@logging` from the recipients]

On Wed, 14 Aug 2024 at 10:24, Volkan Yazıcı  wrote:
> On Tue, Aug 13, 2024 at 8:52 PM Piotr P. Karwasz 
> wrote:
> > There is no special reason why `JsonTemplateLayout` does not support
> > pretty print. It was simply never implemented.
>
> See my response to Amanda
> , there
> are good reasons for not doing it. For one, we first need to start with
> answering "Why shall we do it?". If we hear a compelling use case, it is
> still technically not trivial due to `JsonWriter#writeRawString()` methods.
> Putting that detail aside, I am in favor of guiding users to choose the
> right tool for the right job, instead of trying to make every tool cater
> for all jobs.

When I say "pretty print", I mostly think about supporting BSON,
MessagePack, ByteBuffers and other binary formats. JSON "pretty print"
would be just a side-effect.

JTL is a great tool to:

1. Transform a log event into a Map in an extremely
configurable way.
2. Serialize the Map as JSON using a hardcoded JsonWriter.

Since the second part is hardcoded, we can not use JTL with the NoSQL
Appender. Using it with the JMS or JDBC appenders is limited to
storing strings.

> Making `JsonWriter` pluggable can indeed be a nice feature. It can even be
> served in Log4j 2 without breaking backward compatibility. But it is a
> pretty big undertaking. My suggestion is to implement a small enhancement
> that is simpler: falling back to an external serializer (e.g., Jackson) for
> unknown types. We can easily ship this in Log4j 2 and it addresses the use
> case stated in LOG4J2-3082
> .

I think we have two different concerns here:

1. How to map `Message` implementations to a `String` or `Map`. I think these two conversions should
be hardcoded by the developer by creating the appropriate `Message`
implementation. So if somebody wants to log objects in their code, I
think they should provide a way to map those objects to a
`MapMessage`.
2. How to convert a Log Event into a byte array. As I stated above,
JTL already excels in converting this to a `Map`. It only needs to learn new
serialization formats.

Piotr

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Piotr P. Karwasz]

Hi Gary,

On Wed, 14 Aug 2024 at 12:34, Gary Gregory  wrote:
> I think that to "deactivate" the mailing lists you refer to would be very
> bad and might not even be allowed by Apache.
>
> You cannot/shouldn't force people to create a GitHub (Microsoft) account
> just to talk to us.

Yes, that is an unfortunate limitation of GH Discussions.

On the other hand our mailing lists have other limitations:

* It is not possible to subscribe to a single discussion thread. So
you can either send your question without subscribing and hope that
all participants will Cc you (unlikely), follow the discussion on
`lists.apache.org` (hard to answer without an Apache account) or
subscribe to the list and receive emails for all the other
discussions.
* It is not easy to see all the messages of a thread. Hoping that all
participants of a discussion will set the correct
`In-Reply-To/References` headers is not realistic.

If we are looking for an Apache-hosted replacement for mailing lists,
Apache Answer seems pretty nice. We would just need INFRA to set up a
service.

Piotr

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Gary Gregory]

The issues you bring up are generic Apache issues or mail client issues. I
think that if you want to change the traditional set up, you should check
with ... infra? to see if nuking mailing lists is acceptable.

FWIW, you can see threaded discussions just fine in Apache's Pony mail web
UI. Gmail behaves differently based on the platform.

Gary

On Wed, Aug 14, 2024, 7:24 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Wed, 14 Aug 2024 at 12:34, Gary Gregory  wrote:
> > I think that to "deactivate" the mailing lists you refer to would be very
> > bad and might not even be allowed by Apache.
> >
> > You cannot/shouldn't force people to create a GitHub (Microsoft) account
> > just to talk to us.
>
> Yes, that is an unfortunate limitation of GH Discussions.
>
> On the other hand our mailing lists have other limitations:
>
> * It is not possible to subscribe to a single discussion thread. So
> you can either send your question without subscribing and hope that
> all participants will Cc you (unlikely), follow the discussion on
> `lists.apache.org` (hard to answer without an Apache account) or
> subscribe to the list and receive emails for all the other
> discussions.
> * It is not easy to see all the messages of a thread. Hoping that all
> participants of a discussion will set the correct
> `In-Reply-To/References` headers is not realistic.
>
> If we are looking for an Apache-hosted replacement for mailing lists,
> Apache Answer seems pretty nice. We would just need INFRA to set up a
> service.
>
> Piotr
>

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Ralph Goers]

I thought gitbox was still an alternative to having to use GitHub to submit 
PRs. That said, it wouldn’t be for discussions, etc.

Ralph

> On Aug 14, 2024, at 3:31 AM, Gary Gregory  wrote:
> 
> I think that to "deactivate" the mailing lists you refer to would be very
> bad and might not even be allowed by Apache.
> 
> You cannot/shouldn't force people to create a GitHub (Microsoft) account
> just to talk to us.
> 
> Odd as it sounds, I've had someone told me they would not submit a PR
> because they did not want to create a GH account. It feels
> counterproductive from my POV not to submit PRs but it shouldn't lock
> people out.
> 
> There might also be parts of the world where GH is not available but Apache
> servers are (more of a geopolitical issue).
> 
> Gary
> 
> On Wed, Aug 14, 2024, 3:43 AM Piotr P. Karwasz 
> wrote:
> 
>> Hi Gary,
>> 
>> On Fri, 9 Aug 2024 at 12:15, Gary Gregory  wrote:
>>> While it is a different community, I have received negative feedback in
>>> Commons against the trend to spread information all over the place, and
>> we
>>> don't use GitHub.
>>> 
>>> The TLDR is that in the past it was easier to find information because
>> you
>>> only had the mailing list and later Jira. Now you have multiple mailing
>>> lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus
>>> Slack. Adding to the list is GitHub issues...
>> 
>> Might I propose a split of concerns between GH Discussions and the
>> mailing lists:
>> 
>> * We use GH Discussions as a replacement for `log4j-user`,
>> `log4net-user`, `log4cxx-user`. Two of these mailing lists are dead
>> anyway, since subscribing to a ML for a one-off question is a hustle.
>> * We use `dev@logging` as always for reaching consensus and decisions
>> concerning the directions we choose for development.
>> 
>> BTW: Can we deactivate all the mailing lists except `dev`, `private`
>> and `security`?
>> 
>> Piotr
>> 

Re: Release timeline for log4j 2.24.0?

[John Engebretson]

  Ralph, I get a 404 on that link to your code, could you please verify the
link is good?

FWIW:
- the unit test on StringArrayThreadContextMap thoroughly tests puts
(verified by gets).  I won't rule out a missed case, of course.
- the JMH test on the underlying datastructure (UnmodifiableArrayBackedMap)
is attached at https://github.com/apache/logging-log4j2/issues/2319, as
well as a description of the performance characteristics.

  I'd love to hear more about any conflicting findings, and will dive in
once I get your code.
  Thanks!  :)
John



On Tue, Aug 13, 2024 at 5:07 PM Ralph Goers 
wrote:

> The benchmark code I used was
> https://github.com/apache/logging-log4j2/blob/feature/move-thread-context/log4j-perf-test/src/main/java/org/apache/logging/log4j/perf/jmh/ThreadContextVsScopedContextBenchmark.java
>
> Ralph
>
> > On Aug 13, 2024, at 3:00 PM, Ralph Goers 
> wrote:
> >
> > Piotr, I am still concerned that you never looked into the issues I had
> with StringArrayThreadContextMap. My performance tests were showing that it
> was fast because it wasn’t actually setting values.
> >
> > Ralph
> >
> >> On Aug 13, 2024, at 12:43 PM, Piotr P. Karwasz 
> wrote:
> >>
> >> Hi John,
> >>
> >> On Tue, 13 Aug 2024 at 21:10, John Engebretson 
> wrote:
> >>> HI - just curious when the updated ThreadContextMap will be available?
> >>> The latest release is 2.23.1, over five months ago.
> >>
> >> We just finished a long series of documentation tasks that kept us
> >> occupied for the past since May[1].
> >>
> >> I will be able to concentrate on cutting this almost mythical 2.24.0
> >> release in the next few weeks.
> >>
> >> Piotr
> >>
> >> [1] https://github.com/apache/logging-log4j2/issues/2542
> >
>
>

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Gary Gregory]

Gitbox is just a very thin UI on top of git, no PRs.

Gary




On Wed, Aug 14, 2024, 9:19 AM Ralph Goers 
wrote:

> I thought gitbox was still an alternative to having to use GitHub to
> submit PRs. That said, it wouldn’t be for discussions, etc.
>
> Ralph
>
> > On Aug 14, 2024, at 3:31 AM, Gary Gregory 
> wrote:
> >
> > I think that to "deactivate" the mailing lists you refer to would be very
> > bad and might not even be allowed by Apache.
> >
> > You cannot/shouldn't force people to create a GitHub (Microsoft) account
> > just to talk to us.
> >
> > Odd as it sounds, I've had someone told me they would not submit a PR
> > because they did not want to create a GH account. It feels
> > counterproductive from my POV not to submit PRs but it shouldn't lock
> > people out.
> >
> > There might also be parts of the world where GH is not available but
> Apache
> > servers are (more of a geopolitical issue).
> >
> > Gary
> >
> > On Wed, Aug 14, 2024, 3:43 AM Piotr P. Karwasz 
> > wrote:
> >
> >> Hi Gary,
> >>
> >> On Fri, 9 Aug 2024 at 12:15, Gary Gregory 
> wrote:
> >>> While it is a different community, I have received negative feedback in
> >>> Commons against the trend to spread information all over the place, and
> >> we
> >>> don't use GitHub.
> >>>
> >>> The TLDR is that in the past it was easier to find information because
> >> you
> >>> only had the mailing list and later Jira. Now you have multiple mailing
> >>> lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus
> >>> Slack. Adding to the list is GitHub issues...
> >>
> >> Might I propose a split of concerns between GH Discussions and the
> >> mailing lists:
> >>
> >> * We use GH Discussions as a replacement for `log4j-user`,
> >> `log4net-user`, `log4cxx-user`. Two of these mailing lists are dead
> >> anyway, since subscribing to a ML for a one-off question is a hustle.
> >> * We use `dev@logging` as always for reaching consensus and decisions
> >> concerning the directions we choose for development.
> >>
> >> BTW: Can we deactivate all the mailing lists except `dev`, `private`
> >> and `security`?
> >>
> >> Piotr
> >>
>
>

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Gary Gregory]

In fact, it's been broken for ages: when you click on a gitbox repo, it
redirects to github! It should instead display its UI as it did in the
past...

Gary

On Wed, Aug 14, 2024, 10:58 AM Gary Gregory  wrote:

> Gitbox is just a very thin UI on top of git, no PRs.
>
> Gary
>
>
>
>
> On Wed, Aug 14, 2024, 9:19 AM Ralph Goers 
> wrote:
>
>> I thought gitbox was still an alternative to having to use GitHub to
>> submit PRs. That said, it wouldn’t be for discussions, etc.
>>
>> Ralph
>>
>> > On Aug 14, 2024, at 3:31 AM, Gary Gregory 
>> wrote:
>> >
>> > I think that to "deactivate" the mailing lists you refer to would be
>> very
>> > bad and might not even be allowed by Apache.
>> >
>> > You cannot/shouldn't force people to create a GitHub (Microsoft) account
>> > just to talk to us.
>> >
>> > Odd as it sounds, I've had someone told me they would not submit a PR
>> > because they did not want to create a GH account. It feels
>> > counterproductive from my POV not to submit PRs but it shouldn't lock
>> > people out.
>> >
>> > There might also be parts of the world where GH is not available but
>> Apache
>> > servers are (more of a geopolitical issue).
>> >
>> > Gary
>> >
>> > On Wed, Aug 14, 2024, 3:43 AM Piotr P. Karwasz > >
>> > wrote:
>> >
>> >> Hi Gary,
>> >>
>> >> On Fri, 9 Aug 2024 at 12:15, Gary Gregory 
>> wrote:
>> >>> While it is a different community, I have received negative feedback
>> in
>> >>> Commons against the trend to spread information all over the place,
>> and
>> >> we
>> >>> don't use GitHub.
>> >>>
>> >>> The TLDR is that in the past it was easier to find information because
>> >> you
>> >>> only had the mailing list and later Jira. Now you have multiple
>> mailing
>> >>> lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus
>> >>> Slack. Adding to the list is GitHub issues...
>> >>
>> >> Might I propose a split of concerns between GH Discussions and the
>> >> mailing lists:
>> >>
>> >> * We use GH Discussions as a replacement for `log4j-user`,
>> >> `log4net-user`, `log4cxx-user`. Two of these mailing lists are dead
>> >> anyway, since subscribing to a ML for a one-off question is a hustle.
>> >> * We use `dev@logging` as always for reaching consensus and decisions
>> >> concerning the directions we choose for development.
>> >>
>> >> BTW: Can we deactivate all the mailing lists except `dev`, `private`
>> >> and `security`?
>> >>
>> >> Piotr
>> >>
>>
>>

Re: Open GitHub discussions for Log4j Scala and Kotlin

[Matt Sicker]

Can’t people submit patches via email still?

Also, we have mailing lists for notifications and such that can’t realistically 
be folded in dev@ because of the immense traffic differences.

> On Aug 14, 2024, at 08:17, Ralph Goers  wrote:
> 
> I thought gitbox was still an alternative to having to use GitHub to submit 
> PRs. That said, it wouldn’t be for discussions, etc.
> 
> Ralph
> 
>> On Aug 14, 2024, at 3:31 AM, Gary Gregory  wrote:
>> 
>> I think that to "deactivate" the mailing lists you refer to would be very
>> bad and might not even be allowed by Apache.
>> 
>> You cannot/shouldn't force people to create a GitHub (Microsoft) account
>> just to talk to us.
>> 
>> Odd as it sounds, I've had someone told me they would not submit a PR
>> because they did not want to create a GH account. It feels
>> counterproductive from my POV not to submit PRs but it shouldn't lock
>> people out.
>> 
>> There might also be parts of the world where GH is not available but Apache
>> servers are (more of a geopolitical issue).
>> 
>> Gary
>> 
>> On Wed, Aug 14, 2024, 3:43 AM Piotr P. Karwasz 
>> wrote:
>> 
>>> Hi Gary,
>>> 
>>> On Fri, 9 Aug 2024 at 12:15, Gary Gregory  wrote:
 While it is a different community, I have received negative feedback in
 Commons against the trend to spread information all over the place, and
>>> we
 don't use GitHub.
 
 The TLDR is that in the past it was easier to find information because
>>> you
 only had the mailing list and later Jira. Now you have multiple mailing
 lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus
 Slack. Adding to the list is GitHub issues...
>>> 
>>> Might I propose a split of concerns between GH Discussions and the
>>> mailing lists:
>>> 
>>> * We use GH Discussions as a replacement for `log4j-user`,
>>> `log4net-user`, `log4cxx-user`. Two of these mailing lists are dead
>>> anyway, since subscribing to a ML for a one-off question is a hustle.
>>> * We use `dev@logging` as always for reaching consensus and decisions
>>> concerning the directions we choose for development.
>>> 
>>> BTW: Can we deactivate all the mailing lists except `dev`, `private`
>>> and `security`?
>>> 
>>> Piotr
>>> 
> 

Re: Release timeline for log4j 2.24.0?

[Ralph Goers]

Try this one 
https://github.com/apache/logging-log4j2/blob/2.25.x/log4j-perf-test/src/main/java/org/apache/logging/log4j/perf/jmh/ThreadContextVsScopedContextBenchmark.java

Ralph

> On Aug 14, 2024, at 7:23 AM, John Engebretson  wrote:
> 
>  Ralph, I get a 404 on that link to your code, could you please verify the
> link is good?
> 
> FWIW:
> - the unit test on StringArrayThreadContextMap thoroughly tests puts
> (verified by gets).  I won't rule out a missed case, of course.
> - the JMH test on the underlying datastructure (UnmodifiableArrayBackedMap)
> is attached at https://github.com/apache/logging-log4j2/issues/2319, as
> well as a description of the performance characteristics.
> 
>  I'd love to hear more about any conflicting findings, and will dive in
> once I get your code.
>  Thanks!  :)
>John
> 
> 
> 
> On Tue, Aug 13, 2024 at 5:07 PM Ralph Goers 
> wrote:
> 
>> The benchmark code I used was
>> https://github.com/apache/logging-log4j2/blob/feature/move-thread-context/log4j-perf-test/src/main/java/org/apache/logging/log4j/perf/jmh/ThreadContextVsScopedContextBenchmark.java
>> 
>> Ralph
>> 
>>> On Aug 13, 2024, at 3:00 PM, Ralph Goers 
>> wrote:
>>> 
>>> Piotr, I am still concerned that you never looked into the issues I had
>> with StringArrayThreadContextMap. My performance tests were showing that it
>> was fast because it wasn’t actually setting values.
>>> 
>>> Ralph
>>> 
 On Aug 13, 2024, at 12:43 PM, Piotr P. Karwasz 
>> wrote:
 
 Hi John,
 
 On Tue, 13 Aug 2024 at 21:10, John Engebretson 
>> wrote:
> HI - just curious when the updated ThreadContextMap will be available?
> The latest release is 2.23.1, over five months ago.
 
 We just finished a long series of documentation tasks that kept us
 occupied for the past since May[1].
 
 I will be able to concentrate on cutting this almost mythical 2.24.0
 release in the next few weeks.
 
 Piotr
 
 [1] https://github.com/apache/logging-log4j2/issues/2542
>>> 
>> 
>> 

Re: Release timeline for log4j 2.24.0?

[Ralph Goers]

Note that this uses a custom appender that saves only the last log event 
written. At the end of the test that record is written via System.println. As I 
recall, for the StringArrayThreadContextMap it prints “null”.

Ralph

> On Aug 14, 2024, at 4:45 PM, Ralph Goers  wrote:
> 
> Try this one 
> https://github.com/apache/logging-log4j2/blob/2.25.x/log4j-perf-test/src/main/java/org/apache/logging/log4j/perf/jmh/ThreadContextVsScopedContextBenchmark.java
> 
> Ralph
> 
>> On Aug 14, 2024, at 7:23 AM, John Engebretson  wrote:
>> 
>> Ralph, I get a 404 on that link to your code, could you please verify the
>> link is good?
>> 
>> FWIW:
>> - the unit test on StringArrayThreadContextMap thoroughly tests puts
>> (verified by gets).  I won't rule out a missed case, of course.
>> - the JMH test on the underlying datastructure (UnmodifiableArrayBackedMap)
>> is attached at https://github.com/apache/logging-log4j2/issues/2319, as
>> well as a description of the performance characteristics.
>> 
>> I'd love to hear more about any conflicting findings, and will dive in
>> once I get your code.
>> Thanks!  :)
>>   John
>> 
>> 
>> 
>> On Tue, Aug 13, 2024 at 5:07 PM Ralph Goers 
>> wrote:
>> 
>>> The benchmark code I used was
>>> https://github.com/apache/logging-log4j2/blob/feature/move-thread-context/log4j-perf-test/src/main/java/org/apache/logging/log4j/perf/jmh/ThreadContextVsScopedContextBenchmark.java
>>> 
>>> Ralph
>>> 
 On Aug 13, 2024, at 3:00 PM, Ralph Goers 
>>> wrote:
 
 Piotr, I am still concerned that you never looked into the issues I had
>>> with StringArrayThreadContextMap. My performance tests were showing that it
>>> was fast because it wasn’t actually setting values.
 
 Ralph
 
> On Aug 13, 2024, at 12:43 PM, Piotr P. Karwasz 
>>> wrote:
> 
> Hi John,
> 
> On Tue, 13 Aug 2024 at 21:10, John Engebretson 
>>> wrote:
>> HI - just curious when the updated ThreadContextMap will be available?
>> The latest release is 2.23.1, over five months ago.
> 
> We just finished a long series of documentation tasks that kept us
> occupied for the past since May[1].
> 
> I will be able to concentrate on cutting this almost mythical 2.24.0
> release in the next few weeks.
> 
> Piotr
> 
> [1] https://github.com/apache/logging-log4j2/issues/2542
 
>>> 
>>> 
>