privately to project
> maintainers. In #2949 <https://github.com/apache/logging-log4j2/pull/2949>,
> I implemented fuzz tests for Log4j 2 and their integration with OSS-Fuzz. I
> have documented the details in `FUZZING.adoc`
> <https://github.com/apache/logging-log4j2/blob/2.x/F
t;> than 10 LoC
>>>
>>> ¹ A "fix" is assumed to not introduce a change in the expected behaviour of
>>> the associated component. Changing the expected behaviour does not qualify
>>> a fix.
>>>
>>> *Scoped repositories*
>>>
" is assumed to not introduce a change in the expected behaviour of
>> the associated component. Changing the expected behaviour does not qualify
>> a fix.
>>
>> *Scoped repositories*
>>
>> I suggest extending the scope of this policy to cover the follo
the associated component. Changing the expected behaviour does not qualify
> a fix.
>
> *Scoped repositories*
>
> I suggest extending the scope of this policy to cover the following
> repositories too:
>
>1. `logging-parent`
>2. `logging-log4j-jakarta`
>3. `
On Wed, Sep 18, 2024 at 10:17 AM Piotr P. Karwasz
wrote:
> However, we don't necessarily need to use `2.x` or `main` for those tests.
>
You cannot fix fuzz tests in another branch than `2.x` once OSS-Fuzz starts
pointing there – unless you're willing to waste +2 months for testing a
simple typo:
2. Code typo fixes¹ less than 10 LoC
>3. Infrastructure fixes¹ touching to `pom.xml` or CI scripts, and less
>than 10 LoC
>
> ¹ A "fix" is assumed to not introduce a change in the expected behaviour of
> the associated component. Changing the expected behaviour does n
rent`
2. `logging-log4j-jakarta`
3. `logging-jmx-gui`
4. `logging-samples`
5. `logging-site`
6. `logging-log4net-site`
*Maintainer availability*
The PR-driven workflow can fly because we have full-time maintainers. But
that will not be the case anymore in 2-3 months due to funds dry
This isn’t a vote so I am not going to. If I had to vote I wouldn’t vote for a
policy that requires RTC always. However, I would vote for a policy that
requires RTC when specified criteria are met.
Ralph
> On Sep 17, 2024, at 10:28 AM, Ralph Goers wrote:
>
> First, the obvious. I haven’t comm
27;s not
> > merge them before at least 24 hours have passed.
> > * if a pull request does not receive any review in 72 hours, as a last
> > resort we merge them without a review.
> >
> > I would like to apply this policy to our most active repos:
> >
> > *
Hi
we have only had good experiences with RTC in log4net.
Of course, a lot depends on a review being done in a timely manner.
The feedback is always valuable and I can apply the changes before merging to
main.
But most of the time, a pending review does not stop me from continuing my work.
Either
Hi Matt,
On Tue, 17 Sept 2024 at 20:06, Matt Sicker wrote:
>
> I’m -1 on switching to RTC. Same reason as always. Losing momentum from
> waiting for an unnecessary code review will simply lead to much longer gaps
> between time I spend on the project.
Honestly, momentum is not always a good th
pull/2949>,
I implemented fuzz tests for Log4j 2 and their integration with OSS-Fuzz. I
have documented the details in `FUZZING.adoc`
<https://github.com/apache/logging-log4j2/blob/2.x/FUZZING.adoc>, e.g.,
- How can I run fuzz tests locally?
- How can I view fuzzing failures de
Hello,
After working on Log4j with PRs, I have changed my opinion on CTR/RTC in this
case. Previously, I would have said keep CTR. However, I worked with RTC using
PRs, and my experiences were not bad. I was a bit lost with the comments on the
PR, but I figured it out somehow. I think GitHub
the PR, let's not
> merge them before at least 24 hours have passed.
> * if a pull request does not receive any review in 72 hours, as a last
> resort we merge them without a review.
>
> I would like to apply this policy to our most active repos:
>
> * l-log4j2
> * l-log4j
First, the obvious. I haven’t committed much in a while. The last several I did
I used PRs primarily because it makes it easier for people to review the
changes but I didn’t necessarily wait for a review. For really simple stuff
I've never use a PR. However, with the switch from Jira to GitHub
Maybe we should talk about net vs. J separately?
Gary
On Tue, Sep 17, 2024, 10:53 AM Piotr P. Karwasz
wrote:
> Hi Ralph,
>
> On Tue, 17 Sept 2024 at 15:47, Ralph Goers
> wrote:
> >
> > Why? i.e. - what currently isn’t working?
>
> I merely wish to formalize what is already happening and set up
Hi Ralph,
On Tue, 17 Sept 2024 at 15:47, Ralph Goers wrote:
>
> Why? i.e. - what currently isn’t working?
I merely wish to formalize what is already happening and set up a
branch protection rule to enforce it.
Note that I have never seen a PR in Log4Net being merged without a review.
On the ot
as a last
> resort we merge them without a review.
>
> I would like to apply this policy to our most active repos:
>
> * l-log4j2
> * l-log4j-kotlin
> * l-log4j-scala
> * l-log4j-transform
> * l-log4j-tools
> * l-log4net
>
> I am NOT proposing this chang
Hi Volkan,
On Mon, 16 Sept 2024 at 20:19, Volkan Yazıcı wrote:
> Gary has a failure on L361, that is, it retries every 100ms to succeed with
> `logger.info()` for at most 2mins. I doubt if more waiting will solve the
> problem. I tried to improve that test several times (see its history), but
> W
at the PR, let's not
merge them before at least 24 hours have passed.
* if a pull request does not receive any review in 72 hours, as a last
resort we merge them without a review.
I would like to apply this policy to our most active repos:
* l-log4j2
* l-log4j-kotlin
* l-log4j-scala
* l-
Gary has a failure on L361, that is, it retries every 100ms to succeed with
`logger.info()` for at most 2mins. I doubt if more waiting will solve the
problem. I tried to improve that test several times (see its history), but
Windows just behaves weird with sockets. I'd appreciate it if Windows user
Hi Gary,
On Mon, 16 Sept 2024 at 16:50, Gary D. Gregory wrote:
>
> I just pulled main since we've had changes there, now I get:
>
> [ERROR] Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.31
> s <<< FAILURE! -- in
> org.apache.logging.log4j.core.appender.SocketAppenderReconne
ther work on my PC, so I expect the
> CPU usage to go and down a lot. It would be nice if we could find a way to
> use structures like count down latches to sync up some tests. The build is
> running now... ;-)
>
> Gary
>
> >
> > Piotr
> >
> > PS: On a side note: `log4j-mongodb` might fail on some hosts (e.g. my
> > Debian 12), since it requires some specific versions of OpenSSL and
> > other libraries.
> > That is why I proposed to start the Mongo server from Docker in [1].
> >
> > [1] https://github.com/apache/logging-log4j2/pull/2922
> >
>
f logging
> frameworks. While it supports the MDC it does not support structured messages.
>
> At the moment I don’t think it will support custom ContextDataProviders, but
> that should come for free when I can get log4j-context-data completed.
>
> It also presumes you want all your
While this is nice I don’t think it will result in killing off logging
frameworks. While it supports the MDC it does not support structured messages.
At the moment I don’t think it will support custom ContextDataProviders, but
that should come for free when I can get log4j-context-data
attern layout support
- Structured (i.e., JSON) layout support (New!)
Note that many modern SOA deployment solutions
<https://logging.apache.org/log4j/2.x/soa.html> expect application logs to
be written to the console, which renders the need for specialized appenders
obsolete. Given this,
;> I guess this _might_ fail on an extremely busy host. If your host was
>>> not so busy, we might have a performance problem with LMAX Disruptor.
>>>
>>> I bumped the maximum delay to up to 1 s, hope it helps.
>>
>> Thank you Piotr.
>>
>> Wh
; When I run a build, I run it and then do other work on my PC, so I expect the
> CPU usage to go and down a lot. It would be nice if we could find a way to
> use structures like count down latches to sync up some tests. The build is
> running now... ;-)
>
> Gary
>
> >
> >
do other work on my PC, so I expect the
CPU usage to go and down a lot. It would be nice if we could find a way to use
structures like count down latches to sync up some tests. The build is running
now... ;-)
Gary
>
> Piotr
>
> PS: On a side note: `log4j-mongodb` might fail on som
ptor.
I bumped the maximum delay to up to 1 s, hope it helps.
Piotr
PS: On a side note: `log4j-mongodb` might fail on some hosts (e.g. my
Debian 12), since it requires some specific versions of OpenSSL and
other libraries.
That is why I proposed to start the Mongo server from Docker in [1].
[1] https://github.com/apache/logging-log4j2/pull/2922
Hi All,
Running 'mvn clean install' on git main [1] gives me:
[ERROR] Failures:
[ERROR] AsyncLoggerConfigTest.testSingleFilterInvocation:114
Wanted but not invoked:
appender.append();
-> at
org.apache.logging.log4j.async.logger.AsyncLoggerConfigTest.testSingleFilterInvocation(AsyncLoggerConfig
You're right Ralph, my mistake – apparently I totally missed that page. I
will update email templates (of 8 repositories! 🥴) accordingly.
On Sun, Sep 8, 2024 at 12:29 AM Ralph Goers
wrote:
> https://www.apache.org/legal/release-policy.html#release-announcements
>
> Second sentence of the second
Thanks Piotr. Then you just need to change the announcement template to point
directly to the Downloads page. Of course, it should also continue to have the
link to the full web site.
Ralph
> On Sep 8, 2024, at 12:38 AM, Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Sun, 8 Sept 2024 at 00:29,
Literally the only requirement for the announcement is that it contains a
direct link to where the source archive can be downloaded.
Personally, I like to contain a synopsis of the release (bug fix, minor
enhancements, etc) with 2 or 3 significant items if there are any and then
provide a link
>
> > On Sep 6, 2024, at 3:07 PM, Piotr P. Karwasz
> wrote:
> >
> > Apache Log4j team is pleased to announce the `2.24.0`
> > release. Apache Log4j is a versatile, industrial-strength
> > Java logging framework composed of an API, its implementation,
> > a
Hi Ralph,
On Sat, 7 Sept 2024 at 07:00, Ralph Goers wrote:
>
> As I said previously, you should expect this will NOT get moderated through
> the ASF announce list.
The e-mail has the same format as the one I sent for 2.23.0[1] and is
very similar to the one for 3.0.0-alpha1[2].
Looking at othe
Apache Log4j team is pleased to announce the `2.24.0`
release. Apache Log4j is a versatile, industrial-strength
Java logging framework composed of an API, its implementation,
and components to assist the deployment for various use cases.
For further information (support, download, etc.) see the
the release cycle. As you can
imagine, the Log4j configuration schema is mostly there to help users
with their basic needs. Once users start using arbiters or property
substitution in places where we expect a `boolean`, `int` or `Level`,
errors appear.
We had a very productive discussion with Philip Ha
actoryTest.withAuthentication(UrlConnectionFactoryTest.java:130)
> at java.base/java.lang.reflect.Method.invoke(Method.java:569)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
>
> I can&
voting a release due to local failures, please? I would
> have
> >>> been more than happy to assist you in a video call, instead of
> re-issuing
> >>> the whole release.
> >>>
> >>> On Tue, Sep 3, 2024 at 4:04 PM Gary D. Gregory
> >>> wrote
n more than happy to assist you in a video call, instead of re-issuing
>>> the whole release.
>>>
>>> On Tue, Sep 3, 2024 at 4:04 PM Gary D. Gregory
>>> wrote:
>>>
>>>> -1
>>>>
>>>> On Windows, I deleting my entire
verify artifact:compare
>> -Dreference.repo=%NEXUS_REPO%
>> >
>> > and got:
>> >
>> > [INFO] Minimal buildinfo generated from downloaded artifacts:
>> >
>> C:\Users\ggregory\rc\2.24.0\src\target\reference\log4j-bom-2.24.0.buildinfo
>> &
id, please consider that:
>
> * Around 10% of all builds fail due to a test. You can find a list of
> broken tests on Develocity[1] and try to fix them.
> * The SBOM is generated based on the dependencies in your local Maven
> repo. If you happen to be the Release Manager of some of
gt; On Tue, Sep 3, 2024 at 4:04 PM Gary D. Gregory
>>> wrote:
>>>
>>>> -1
>>>>
>>>> On Windows, I deleting my entire .m2/repository folder and then ran
>>>>
>>>> mvnw -Prelease clean verify artifact:compare
>>> -D
> > wrote:
> >
> > > -1
> > >
> > > On Windows, I deleting my entire .m2/repository folder and then ran
> > >
> > > mvnw -Prelease clean verify artifact:compare
> > -Dreference.repo=%NEXUS_REPO%
> > >
> >
gt; On Windows, I deleting my entire .m2/repository folder and then ran
> >
> > mvnw -Prelease clean verify artifact:compare
> -Dreference.repo=%NEXUS_REPO%
> >
> > and got:
> >
> > [INFO] Minimal buildinfo generated from downloaded artifacts:
> >
> C:\
se Manager of some of Log4j
dependencies, you might have some pre-releases and RCs in the repo
instead of the official versions.
Piotr
[1]
https://ge.apache.org/scans/tests?search.relativeStartTime=P28D&search.rootProjectNames=Apache%20Log4j%20BOM&search.timeZoneId=Europe%2FWarsaw#
wrote:
> -1
>
> On Windows, I deleting my entire .m2/repository folder and then ran
>
> mvnw -Prelease clean verify artifact:compare -Dreference.repo=%NEXUS_REPO%
>
> and got:
>
> [INFO] Minimal buildinfo generated from downloaded artifacts:
> C:\Users\ggregory\rc\2.2
h(ArrayList.java:1511)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
I can't dig in now :-( day job calls...
Gary
On 2024/09/03 16:56:42 "Piotr P. Karwasz" wrote:
> This is a vote to release the Apache Log4j `2.24.0`.
>
> Website: https://logging.staged.apache.org/
This is a vote to release the Apache Log4j `2.24.0`.
Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
GitHub: https://github.com/apache/logging-log4j2
Commit: c79ae325f6a21af45526c202f121bfced188613e
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j/2.24.0
Thank you Piotr!
Gary
On Tue, Sep 3, 2024, 11:17 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> On Sat, 31 Aug 2024 at 21:30, Piotr P. Karwasz
> wrote:
> >
> > This is a vote to release the Apache Log4j `2.24.0`.
> >
> > Website: https://logging.staged.apache.or
Hi all,
On Sat, 31 Aug 2024 at 21:30, Piotr P. Karwasz wrote:
>
> This is a vote to release the Apache Log4j `2.24.0`.
>
> Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 08053687456f6be61ee820
-1
On Windows, I deleting my entire .m2/repository folder and then ran
mvnw -Prelease clean verify artifact:compare -Dreference.repo=%NEXUS_REPO%
and got:
[INFO] Minimal buildinfo generated from downloaded artifacts:
C:\Users\ggregory\rc\2.24.0\src\target\reference\log4j-bom-2.24.0.buildinfo
Note that I add "clean" *(why does the kit not use "clean"?)
mvnw -Prelease clean verify artifact:compare -Dreference.repo=$NEXUS_REPO
Gary
On 2024/09/03 13:21:32 "Gary D. Gregory" wrote:
> It's fails differently on Ubuntu:
>
> ...
> [INFO] --- a
Note that I add "clean" *(why does the kit not use "clean"?)
mvnw -Prelease clean verify artifact:compare -Dreference.repo=$NEXUS_REPO
Gary
On 2024/09/03 13:21:32 "Gary D. Gregory" wrote:
> It's fails differently on Ubuntu:
>
> ...
> [INFO] --- a
It's fails differently on Ubuntu:
...
[INFO] --- artifact:3.5.1:compare (default-cli) @ log4j-api ---
[WARNING] property is inherited from outside
the reactor, it should be defined in parent POM from reactor
/mnt/c/Users/ggregory/rc/2.24.0/src/.flattened-pom.xml
[INFO] Reference buildinfo
y
On 2024/08/31 19:30:00 "Piotr P. Karwasz" wrote:
> This is a vote to release the Apache Log4j `2.24.0`.
>
> Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 08053687456f6be61ee8206da782a3d05192
:
[INFO]
[ERROR] Failures:
[ERROR] HttpAppenderTest.testAppendCustomHeader:254 Expected at least one
request matching: {
"url" : "/test/log4j/",
"method" : "POST",
"headers" : {
"Host" : {
"contains" : "
Just looked at apache-log4j-2.24.0-email-announce.txt in the dist directory.
(I am not actually sure what that is there to be honest). The email does NOT
include a download link so will definitely be rejected.
Ralph
> On Aug 31, 2024, at 1:55 PM, Ralph Goers wrote:
>
> I look
[INFO]
[INFO] Reactor Summary for Apache Log4j BOM 2.24.0:
[INFO]
[INFO] Apache Log4j BOM ... SUCCESS [ 20.229 s]
[INFO] Apache Log4j Parent SUCCESS [ 0.697 s]
[INFO] Apache Log4j API Java 9 su
On Sun, Sep 1, 2024 at 6:01 PM Piotr P. Karwasz wrote:
>
> Hi Gary,
>
> On Sun, 1 Sept 2024 at 23:34, Gary Gregory wrote:
> > Now I get:
> >
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR] NetUtilsTest.testCanonicalHostName:78
> > Expecting actual:
> > "localhost"
> > to cont
Hi Gary,
On Sun, 1 Sept 2024 at 23:34, Gary Gregory wrote:
> Now I get:
>
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] NetUtilsTest.testCanonicalHostName:78
> Expecting actual:
> "localhost"
> to contain:
> "."
> [INFO]
> [ERROR] Tests run: 2253, Failures: 1, Errors: 0, Skipped:
On Sun, Sep 1, 2024 at 5:09 PM Piotr P. Karwasz wrote:
>
> Hi Gary,
>
> On Sun, 1 Sept 2024 at 23:00, Piotr P. Karwasz
> wrote:
> > On Sun, 1 Sept 2024 at 22:44, Gary Gregory wrote:
> > > [ERROR] sha512 mismatch log4j-bom-2.24.0-cyclonedx.xml: investigate
>
Hi Gary,
On Sun, 1 Sept 2024 at 23:00, Piotr P. Karwasz wrote:
> On Sun, 1 Sept 2024 at 22:44, Gary Gregory wrote:
> > [ERROR] sha512 mismatch log4j-bom-2.24.0-cyclonedx.xml: investigate
> > with diffoscope
> > target/reference/org.apache.logging.log4j/log4j-bom-2.24.0-cyc
Hi Gary,
On Sun, 1 Sept 2024 at 22:44, Gary Gregory wrote:
> [ERROR] sha512 mismatch log4j-bom-2.24.0-cyclonedx.xml: investigate
> with diffoscope
> target/reference/org.apache.logging.log4j/log4j-bom-2.24.0-cyclonedx.xml
> target/bom.xml
Could you investigate with `diff
targ
Hi All,
Thank you Piotr for preparing the RC.
Using the review kit, this is what I get on the step 'sh mvnw
-Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO'
[INFO] --- artifact:3.5.1:compare (default-cli) @ log4j-bom ---
[WARNING] property is inherited, it
should be
to release the Apache Log4j `2.24.0`.
>
> Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
> GitHub: https://github.com/apache/logging-log4j2
> Commit: 08053687456f6be61ee8206da782a3d051928a57
> Distribution: https://dist.apache.org/repos/dist/dev/
issues. Just be aware you are likely to
> have problems announcing the release.
On Sat, 31 Aug 2024 at 23:00, Ralph Goers wrote:
> "log4j-flume-ngT
> The module has been moved to the Flume project and follows the Apache
> Flume release lifecycle.
>
> We NEVER disc
stuff into
Log4j-core. I haven’t actually checked the release yet but I am assuming that
happened.
Ralph
> On Aug 31, 2024, at 2:21 PM, Gary Gregory wrote:
>
> I've not looked at details but Ralph's comment hints that we need to
> explain to users how to migrate if it&#
by Scoped Context, which, unlike
> Thread Context,
> • is safe to use in servlet applications
> • can store any Object-typed value
>
>
> While I totally agree with this I was under the impression that
> ScopedContext was removed from Log4j 2.24.0, so this will lead to user
The API section has
Thread Context is mostly superseded by Scoped Context, which, unlike Thread
Context,
• is safe to use in servlet applications
• can store any Object-typed value
While I totally agree with this I was under the impression that ScopedContext
was removed from Log4j
The release notes page says:
"log4j-flume-ngT
The module has been moved to the Flume project and follows the Apache
Flume release lifecycle.
We NEVER discussed this. We simply discussed moving it to another repo. As in
3.0.0, where more modules are split out, I believe it would be
te -1 due to any web site issues. Just be aware you are likely to have
problems announcing the release.
Ralph
> On Aug 31, 2024, at 12:30 PM, Piotr P. Karwasz
> wrote:
>
> This is a vote to release the Apache Log4j `2.24.0`.
>
> Website: https://logging.staged.apache.org/
This is a vote to release the Apache Log4j `2.24.0`.
Website: https://logging.staged.apache.org/log4j/2.24.0/index.html
GitHub: https://github.com/apache/logging-log4j2
Commit: 08053687456f6be61ee8206da782a3d051928a57
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j
Nexus: https
Hi Ralph,
On Fri, 30 Aug 2024 at 08:44, Piotr P. Karwasz wrote:
> On Thu, 29 Aug 2024 at 23:32, Ralph Goers wrote:
> > So I will say I am fine with moving it to its own module. Can it be moved
> > while keeping the 2.x and main branches?
>
> Sure, I created a `logging-lo
Hi Ralph,
On Thu, 29 Aug 2024 at 23:32, Ralph Goers wrote:
> So I will say I am fine with moving it to its own module. Can it be moved
> while keeping the 2.x and main branches?
Sure, I created a `logging-log4j-flume` repository and I'll move both
branches there preserving the com
My only concern for splitting it out is the same one I have for all of our
modules, whether they reside in the same repo as Log4j or not. That is, they
all need to be tested against the latest versions of Log4j.
In the case of the Flume appender unless something specifically is being done
to
I’d be ok with splitting it out.
> On Aug 29, 2024, at 07:12, Piotr P. Karwasz wrote:
>
> Hi all,
>
> The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
>
> * an Avro appender, that only depends on Avro and Avro IPC. Since it
> only communicates wi
Hi,
I'd like to follow Ralph's lead on Flune related topics.
Gary
On Thu, Aug 29, 2024, 8:12 AM Piotr P. Karwasz
wrote:
> Hi all,
>
> The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
>
> * an Avro appender, that only depends on Avro and
I support the idea of removing `log4j-flume-ng` from `main` and figuring
out a resolution later. I think it is too early to decide on how to further
proceed with `log4j-flume-ng`; moving to a separate repository, merging it
back to `main`, etc. The important thing is, we can always add it back to
Hi all,
The `log4j-flume-ng` module _de facto_ contains 3 different appenders:
* an Avro appender, that only depends on Avro and Avro IPC. Since it
only communicates with Flume via network, it doesn't need to even
depend on Flume, it just needs to use the same protocol.
* a Persistent app
Hi John,
On Thu, 15 Aug 2024 at 17:33, John Engebretson wrote:
> Thanks Ralph! Unfortunately the test you attached doesn't attempt any
> log statements against thread thread context. The only test performed on
> this implementation loops through the keys that are present, and provides
> ident
or 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/ThreadCo
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 t
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 co
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
>>> m
;> >>> 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
>> >>
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 discussi
7 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, a
Hub 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-
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 be
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
ck. 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 sub
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
Hi Ralph,
On Wed, 14 Aug 2024 at 00:00, 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.
It's on my TODO list. Note
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
Isn't that assertable from a unit test?
Gary
On Tue, Aug 13, 2024, 6: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 val
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
John,
You should test our snapshot builds just in case ;-)
Gary
On Tue, Aug 13, 2024, 3: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
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].
1 - 100 of 3723 matches
Mail list logo
