I just looked at my Maven emails. It looks like they migrated all their Jira
issues into GitHub issues or something which is why I had so many emails.
Ralph
> On Jun 17, 2025, at 9:01 AM, Ralph Goers wrote:
>
> I am actively working on Log4j-Audit at the moment. I am currently upgrad
In the last 6 months, I haven't noticed any progress regarding
> these projects. Though you might have changes ready locally, or I might
> have missed your activity. Would you mind updating us on your progress and
> plans, please?
>
> On Wed, Jan 15, 2025 at 2:21 PM Ralph
I am finding this email confusing. I think it is due to the formatting but I am
not sure. I am making my best guess.
Vote 1: Enable certain branch protection features on the code branches (`2.x`
and `main`) of all non-dormant Java repos:
I can’t vote on this as I don’t know what the impact of t
OK. With the new descriptions I can vote on this.
> On Apr 2, 2025, at 10:12 AM, Piotr P. Karwasz
> wrote:
>
> Hi all,
> Sorry, my e-mail client reformatted some lines.
> So, the concerned repos are all non-dormant Java repos: l-admin, l-jdk,
> l-jmx-gui, l-log4j2, l-log4j-jakarta, l-log4j-kot
I think the failures you note should cause the whole configuration to fail. The
user should be able to control whether that failure surfaces an exception to
the application.
Ralph
> On Mar 3, 2025, at 4:53 AM, Piotr P. Karwasz
> wrote:
>
> Hi all,
>
> Configuration problems in our builders
I think what you propose makes a lot of sense.
Ralph
> On Feb 25, 2025, at 9:16 AM, Piotr P. Karwasz
> wrote:
>
> Hi Ralph,
>
> On 25.02.2025 14:36, Ralph Goers wrote:
>> Just an FYI - in Spring Boot 3 if you specify an override file that is not
>> present the
Just an FYI - in Spring Boot 3 if you specify an override file that is not
present the application will fail to start. This behavior is different then
what log4j-spring-boot does. It seems that if you include the log4j-spring-boot
jar then the error is avoided.
See https://github.com/spring-pro
Why does the BurstFilter not address your concern?
Ralph
> On Jan 27, 2025, at 5:59 PM, Yuepeng Pan wrote:
>
> Thanks Volkan for the quick response.
>
>> Could you share an example of how your
>> filter is used in a configuration file, please?
> Yes, glad to do it.
>
> The specific examples a
I must be misunderstanding. IIUC you are proposing that to eliminate optional
dependencies we create a bunch of empty jars, presumably with a pom that has
the dependency as required. How exactly does that help? Doesn’t that new,
empty artifact just become an optional dependency? Isn’t it requi
-1 on Flume
Despite you not seeing visible evidence I am still working on these. I am
actually fairly confident I will need to create releases of Flume in the next 6
months.
Ralph
> On Jan 15, 2025, at 2:05 AM, Volkan Yazıcı wrote:
>
> Chainsaw and Flume projects have been moved to dormant
Some huge points are being overlooked in this discussion.
1. A Plugin is NOT a Java service. You cannot manually create the
META-INF/services entry for your plugin as the plugin system won’t recognize it.
2. A Plugin service is a collection of plugins. This is intentional as loading
all the plug
Do you two have jobs lined up? I’m curious what you will be doing.
Ralph
> On Dec 1, 2024, at 3:50 AM, Piotr P. Karwasz
> wrote:
>
> Hi all,
>
> I think we should have a PMC meeting in December to summarize what we
> achieved in 2024. How does Sunday, 15th sound?
>
> A rapid draft of the a
Log4j core has a version compatibility comparison just for this reason. If core
is updated to require some new feature in the API then the version it checks
for needs to be updated and Log4j-API needs to update its version when it adds
new features.
Ralph
> On Nov 14, 2024, at 3:25 AM, Piotr P
Log4j 2.3.x and 2.12.x don’t need votes. We declared that we were no longer
supporting Java 6 and then Java 7 and that those would be the last releases to
do so. We made an exception for Log4Shell and created patches for both since
the security exposure was so bad. Those release lines are clearl
Why doesn’t it say what the failure is?
Ralph
> On Nov 9, 2024, at 6:11 AM, Gary Gregory wrote:
>
> Hi All,
>
> Running:
>
> mvn clean verify -Dreference.repo=
> https://repository.apache.org/content/repositories/orgapachelogging-1307
> -Prelease artifact:compare
>
> I get this failure:
>
>
> On Nov 2, 2024, at 3:51 PM, Piotr P. Karwasz
> wrote:
>
> This would be the same setting as in Commons Logging, so I guess I would be
> OK with that, if we keep an extension mechanism in the API. We could probably
> split the implementation in two parts: Log4j Core can receive his
> impl
To be honest, I have never been a fan of this kind of interface because:
1. getLoggerContext returns a meaningless object. The object returned only has
value if you know what it is and if you do then you might as well be tied to
whatever the implementation is.
2. You are passing in an arbitrary
Apache Log4j Transformation Tools team is pleased to announce the `0.2.0`
release. This project contains tools for binary postprocessing of
projects that use the Apache Log4j API. For further information
(support, download, etc.) see the project website[1].
[1] https://logging.apache.org/log4j/tra
che-maven-3.9.9
> Java version: 17.0.12, vendor: Eclipse Adoptium, runtime: C:\Program
> Files\Eclipse Adoptium\jdk-17.0.12.7-hotspot
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "wind
This vote has passed with +1 votes from Piotr, Gary and Ralph. I will continue
with the release process.
Ralph
This is a vote to release the Apache Log4j Transformation Tools `0.2.0`.
Website: https://logging.staged.apache.org/log4j/transform-0.2.0
GitHub: https://github.com/apache/logging-log4j-transform
Commit: 074f4c67d0514c52eb52a0139d0086b20d60d25c
Distribution:
https://dist.apache.org/repos/dist/d
Gary,
With the changes that have been made the bridges only have a dependency on
Logj4 API - which is only in the 2.x branch. Should these artifacts only be on
the 2.x branch as well?
These bridges don’t change nearly as often as core or even api do. IMO
releasing them with every release does
I am OK with this plan.
I understand why Volkan wants -api though. If log4j-api was named ALA4J (Apache
Logging API for Java) then you would rightfully want to name the bridge
slf4j-to-ala4j. By naming it slf4j-to-log4j it is ambiguous.
Ralph
> On Oct 22, 2024, at 9:52 AM, Piotr P. Karwasz w
er things are also using Slack. On the other
>> hand, I had to disable notifications from Slack due to people misusing it
>> to DM me instead of sending emails to the Secretary properly (unrelated to
>> Log4j).
>>
>>> On Oct 14, 2024, at 15:53, Ralph Goers
>>
Volkan,
Piotr’s proposal sounds reasonable to me. Does it to you?
Ralph
> On Oct 15, 2024, at 4:36 AM, Piotr P. Karwasz wrote:
>
> Hi Volkan,
>
> On Mon, 14 Oct 2024 at 21:30, Volkan Yazıcı wrote:
>> Hence, I propose switching all layouts to use `DateTimeFormatter`, unless
>> the `log4j.time
inct instants within the same day to avoid cache misses in
> `FixedDateFormat`'s cache on the `-MM-dd` part, which is updated daily
> at midnight. That is why `FixedDF` figures are more or less the same for
> both patterns.
>
> On Mon, Oct 14, 2024 at 9:48 PM Ralph Goers
> wr
ve been sent to me. I
> have a regular habit of reading email nearly every day, but developing new
> habits is unlikely to stick.
>
>> On Oct 14, 2024, at 14:50, Ralph Goers wrote:
>>
>> Maybe we just need to start contributing to PonyMail to improve the UI to
Maybe we just need to start contributing to PonyMail to improve the UI to
eliminate actually needing the email delivered to our accounts.
I am only 1/4 serious about this. There has to be a better solution.
Ralph
> On Oct 14, 2024, at 10:25 AM, Matt Sicker wrote:
>
> I didn’t get the original
Before I can weigh in one way or another I would need to know what the
performance difference is between DateTimeFormatter and the Fixed and Fast
classes, at least where they are working properly. Any such test should include
the caching otherwise you would be comparing worst case performance.
Maybe. I will have to look at it and I can’t get to it until a bit later.
Ralph
> On Oct 10, 2024, at 11:16 AM, Volkan Yazıcı wrote:
>
> The GC-free Thread Context Map has been an opt-in feature. I would like to
> make it the default if
>
> userConfiguredThreadContextMap == null
>&& !I
nfigure Log4j to throw an exception when a
> log event criterion is met. Log4j provides filters which is the closest
> feature for testing log events for criteria. So, it seems to me like
> filters are the best place to implement this feature. I don't think we need
> to invent some
This just feels wrong. Filters are for determining whether log events should be
logged. This Filter doesn’t have anything to do with that. It is more like an
interceptor.
Secondly, I don’t like that the only criteria it is able to use to determine
whether to throw an exception is the log level
-1
Ralph
> On Oct 3, 2024, at 4:00 AM, Piotr P. Karwasz wrote:
>
> Hi Christian,
>
> On Wed, 2 Oct 2024 at 21:30, Christian Grobmeier wrote:
>> Please vote:
>>
>> [] +1, label Flume as dormant
>> [] -1, don't label Flume as dormant because...
>
> +1, label Flume as dormant
>
> Honestly I h
ull-time maintainers) and
>> no exemptions might jeopardize the streamlining of development in the long
>> run. That said, as Christian noted, we can adapt/drop the policy later on
>> if needed.
>>
>> I disagree with Matt's *"losing momentum from waiting for a
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.
minor, so you only doing PRs makes sense.
Ralph
> On Sep 17, 2024, at 7:52 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 a
Why? i.e. - what currently isn’t working?
Ralph
> On Sep 17, 2024, at 1:30 AM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Inspired by the way the Log4Net team works, I would like to propose a
> switch from our CTR policy to RTC:
>
> * every change to the main branches should go through a pull re
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 completed
Even with Gary volunteering I don’t see a reason why beta3 would need to wait
for that.
Ralph
> On Sep 10, 2024, at 8:08 AM, Piotr P. Karwasz wrote:
>
> Hi Gary,
>
> On Tue, 10 Sept 2024 at 14:40, Gary Gregory wrote:
>>
>> I can do the File to Path work if everyone is OK with the idea.
>
>
t 2024 at 00:29, Ralph Goers wrote:
>> However, I either didn’t look carefully enough or the page changed (more
>> likely the first than the second) as I did not notice that the downloads
>> page actually does have the specific links for the artifacts. In my first
>>
to the release notes.
Ralph
> On Sep 6, 2024, at 11:49 PM, Piotr P. Karwasz wrote:
>
> 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 l
Personally, I would appreciate a document I can read that documents the build
process. Even though I am sure it is all Maven plugins of some kind it isn’t
unusual for the order and configuration of the plugins to be important.
I’d really like to know what I need to do to get it to work for some
Thanks Piotr. It is good to know this as I often have lots of source code and
build from various things on my computer.
Ralph
> On Sep 3, 2024, at 12:45 PM, Piotr P. Karwasz wrote:
>
> Hi Volkan,
>
> On Tue, 3 Sept 2024 at 20:54, Volkan Yazıcı wrote:
>> My point is, 3 people verified the rel
? Clean takes a no time. It ensures no junk is lying around.
Ralph
> On Sep 3, 2024, at 10:58 AM, Volkan Yazıcı wrote:
>
> I will remove `clean`, since there is nothing to clean.
> We shouldn't add unnecessary overhead.
>
> On Tue, Sep 3, 2024 at 7:01 PM Piotr P. Karwasz
> wrote:
>
>> Hi Gar
Volkan,
I think Gary told you. He has the right to complain and vote on a release as
he feels. Although I believe it is wrong to do so, I could have voted -1 on the
release do to the release notes and web site issues. With 3 +1 votes Piotr
always had the option to go ahead with the release any
+1
Verified the signatures and checksums
I rann the build twice with both failing but each failing differently.
My machine info
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /opt/maven/maven
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/Java
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
x27;s anything more than an import
> change. WDYT?
>
> Gary
>
> On Sat, Aug 31, 2024, 5:06 PM Ralph Goers
> wrote:
>
>> The API section has
>>
>> Thread Context is mostly superseded by Scoped Context, which, unlike
>> Thread Context,
>>• i
2.24.0, so this will lead to user questions.
Ralph
> On Aug 31, 2024, at 2:00 PM, Ralph Goers wrote:
>
> 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
more appropriate
to say that they will have their own release cycles.
Ralph
> On Aug 31, 2024, at 1:55 PM, Ralph Goers wrote:
>
> I looked at the download page and it does NOT meet the requirements for a
> release announcement:
> "Announcements must contain a link to the r
I looked at the download page and it does NOT meet the requirements for a
release announcement:
"Announcements must contain a link to the relevant download page for the
source.” The download page contains a link to a generic directory listing of
all Logging Services releases.
You can quibble h
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
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
; 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
>
>
>
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 al
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
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
I am fine with this plan.
Ralph
> On Aug 9, 2024, at 1:35 PM, Piotr P. Karwasz wrote:
>
> Hi Matt,
>
> On Fri, 9 Aug 2024 at 20:29, Matt Sicker wrote:
>>
>> Well, one thing that changed in JUL is that it requires the java.logging
>> module. Otherwise, the Java 8+ stuff is for the System.Log
I believe I have asked for a log4j-its module for a while now since that is the
only way you can validate modules actually work together. I am fine with it
being in a separate repo.
Ralph
> On Aug 8, 2024, at 11:35 PM, Piotr P. Karwasz wrote:
>
> Hi all,
>
> Unless I am mistaken, adding test
What am I missing here? In looking at all the project sites none of our logos
have a feather in them. Once the ASF provides a replacement logo we can simply
replace it.
Why are we talking about new logos? FWIW none of our projects existed in the
1980s so I don’t know where that comment came fr
> On Jul 17, 2024, at 2:11 PM, Piotr P. Karwasz wrote:
>
> Hi Matt,
>
> On Wed, 17 Jul 2024 at 19:03, Matt Sicker wrote:
>> I’ll note one design constraint behind property sources and lookups.
>> Property sources are defined in the API while lookups are defined in Core.
>
> Since Log4j Cor
> On Jul 17, 2024, at 3:09 AM, Piotr P. Karwasz wrote:
>
> Hi Ralph,
>
> On Tue, 16 Jul 2024 at 15:17, Ralph Goers wrote:
>>> * we have a `SpringLookup` and a `SpringPropertySource`.
>>
>> SpringLookup returns the value of a key. A property source loc
> On Jul 15, 2024, at 6:30 AM, Piotr P. Karwasz wrote:
>
> Since the creation of Log4j 2, the concepts of `PropertySource` and
> `StrLookup` and the concepts of `StrLookup` and
> `LogEventPatternConverter` have strongly converged to each other.
> We might consider removing some of them in Log4
I sure hope we're not
> using it.
>
> Gary
>
> On Tue, May 28, 2024, 12:27 PM Matt Sicker wrote:
>
>> Probably discussions about the ScopedContext API in general.
>>
>>> On May 26, 2024, at 14:49, Ralph Goers
>> wrote:
>>
Several of the PMC members met yesterday to primarily discuss the ScopedContext
and getting release 2.24.0 ready. The notes from that meeting are at
https://docs.google.com/document/d/1U7IXrgNYKX3aFE1IEVDmYradt5nxBn2NJM8P9_f1f0M/edit?usp=sharing.
Ralph
dentically to the current code built on 17.
> Is that correct?
> John
>
> On Thu, May 30, 2024 at 10:04 AM Ralph Goers
> wrote:
>
>>
>>
>>> On May 30, 2024, at 7:43 AM, John Engebretson
>> wrote:
>>>
>>> I agree on the complexity
> On May 30, 2024, at 7:43 AM, John Engebretson wrote:
>
> I agree on the complexity argument - and FWIW we still have many apps on
> JDK 8 and are intimidated by the Spring upgrade, so I understand that. :)
> Sounds like we agree there's no runtime impact?
> John
>
I am not sure what y
> On May 30, 2024, at 6:37 AM, Engebretson, John
> wrote:
>
> On 2024/04/10 01:45:19 Ralph Goers wrote:
>>
>>
>>> On Apr 9, 2024, at 3:52 PM, Piotr P. Karwasz wrote:
>>>
>>>
>>> BTW: Maybe SLF4J still uses Java 8, but th
> On May 26, 2024, at 11:06 AM, Christian Grobmeier
> wrote:
>
>
>
> On Sat, May 25, 2024, at 04:22, Gary Gregory wrote:
>> I'd like to have the PMC meet to review and discuss ScopedContext,
>> which I am not caught up on, and whatever else we should chat about.
>
> Me too.
>
> I feel tha
no application changes. We like
> that outcome. :)
> John
>
> On Fri, May 24, 2024 at 1:47 PM Ralph Goers
> wrote:
>
>>
>>
>>> On May 24, 2024, at 11:10 AM, Piotr P. Karwasz
>> wrote:
>>>
>>> Hi John,
>>>
>>>
> On May 24, 2024, at 11:10 AM, Piotr P. Karwasz
> wrote:
>
> Hi John,
>
> On Fri, 24 May 2024 at 17:17, John Engebretson wrote:
>> As
> I stated several times, 'ThreadContext.get()` is a mistake, because it
> allows users to abuse the API and transport logging-unrelated data
> through `Th
IMO, yes. I had them due to something needed them in the tooling we used to
use. But like code, tags in the docs aren’t very valuable.
Ralph
> On May 14, 2024, at 8:00 AM, Piotr P. Karwasz wrote:
>
> Can we remove author lines in documentation pages?
>
> These lines are becoming crowded and s
The IDE lets you view the page you are editing but generally it doesn’t show
you the nav or the rest of the site. I am also not confident that everything
will be styled exactly the same as it will appear in the browser.
So, in short, the IDE is great for editing but I like to do my reviews on a
Volkan,
I completely agree with you. I prefer to review my site changes either in
target/site or by doing a deploy to a local directly. In both cases I use the
file protocol to view it.
Ralph
> On May 8, 2024, at 5:55 AM, Volkan Yazıcı wrote:
>
> All non-default `html_extension_style` option
Periodically I have tried to go through old issues and close those that I know
will get no activity. I’d prefer to do that than just close them all. Now that
Jira is locked down at least the list of issues there will never grow.
In doing that I would actually recommend creating an issue at GitHu
I have always viewed index.html as a special case. When navigating to the root
of a site - l.a.o/log4j/2.x/ - should be sufficient as it should default to
index.html. However, the “real” url includes index.html.
Other pages should always be whatever.html IMO.
Ralph
> On Apr 20, 2024, at 1:17
Did we make a decision on this?
Ralph
> On Apr 8, 2024, at 4:02 PM, Ralph Goers wrote:
>
>
>
>> On Apr 8, 2024, at 2:40 PM, Jochen Wiedmann
>> wrote:
>>
>> On Mon, Apr 8, 2024 at 1:11 PM Apache wrote:
>>
>>> My opinion is to d
In theory that library could use the ContextData class I just added to get
context data no matter how it got there. However, the Micrometer library’s
setValue and getValue set and retrieve the full map, not values. That won’t
play nice with a ScopedContext since once you set it you would immedia
> On Apr 9, 2024, at 3:52 PM, Piotr P. Karwasz wrote:
>
>
> BTW: Maybe SLF4J still uses Java 8, but the latest Logback uses Java 11.
Ask me if I care about Logback. ;-)
Ralph
You are forgetting one small thing. Plugins in 3.x use ServiceLoader while 2.x
uses the Log4j2Plugins.dat file. While 3.x supports the old format it will be
much better for users to not have to use the transformer when building uber
jars as most tooling supports ServiceLoader out of the box.
N
> On Apr 8, 2024, at 2:40 PM, Jochen Wiedmann wrote:
>
> On Mon, Apr 8, 2024 at 1:11 PM Apache wrote:
>
>> My opinion is to drop it from 3.0.0. 2.x is going to live a long time still.
>> By the time it dies Log4J 1.x will have been dead well over 15 years, maybe
>> even 20. That would give
re where to even find the current javadocs for the API.
> javadoc.io only seems to have this alpha release.
>
>
>> On Mar 21, 2024, at 04:34, Volkan Yazıcı wrote:
>>
>> Ralph, could you show how those two users can use a `MessageFactory` to
>> create `Logger`s wi
> On Mar 22, 2024, at 1:45 AM, Volkan Yazıcı wrote:
>
> No, it is not the same thing Matt. Let me be as explicit as I can:
>
> var logger0 = getLogger(); // MDC: {}
> var logger1 = logger0.withContextData("x", 1); // MDC: {x: 1}
> var logger2 = logger1.withContextData("y", 2); // MDC: {x: 1
> On Mar 21, 2024, at 3:19 PM, Piotr P. Karwasz wrote:
>
>
> PS: In the `main` branch I plan to replace the default
> ReusableMessageFactory with ReusableLogEventFactory:
>
> * this change should have a minimal impact on memory (events are not
> much larger than messages),
> * it can skip a
> On Mar 21, 2024, at 2:48 PM, Raman Gupta wrote:
>
> On Thu, Mar 21, 2024 at 5:30 AM Piotr P. Karwasz
> wrote:
>
>> Hi Ralph,
>>
>> On Thu, 21 Mar 2024 at 07:03, Ralph Goers
>> wrote:
>>>> 1. Raman and Mikko would like to bind cont
roviders. You really
can only have one ContextDataInjector. Also, please note that
ContextDataInjector is called while constructing the LogEvent. The LogEvent
isn't passed the Logger, only the LoggerName. Looking up the Logger to do this
is yet another way to slow down logging.
>
> On
> On Mar 18, 2024, at 2:39 AM, Piotr P. Karwasz wrote:
>
> Hi,
>
> Given the ongoing context data propagation in three Github
> issues/PRs/discussions (cf. [1], [2] and [3]). I think we should move
> the debate to the mailing list, which guarantees the maximal reachout.
>
> == Problem summar
asz wrote:
>
> Hi Ralph,
>
> On Tue, 19 Mar 2024 at 07:45, Ralph Goers wrote:
>> 2. The links you provide describe the problem of passing contexts to threads
>> magnificently. Unfortunately, they solve it by requiring you NOT to use
>> standard JDK tooling for ma
Interesting. I hadn’t noticed that the GitHub repos had changed urls.
Ralph
> On Mar 19, 2024, at 1:40 PM, Jan Friedrich wrote:
>
> Hi Sebb,
>
> is this what you want?
>
> https://github.com/apache/logging-flume/pull/421
>
> Regards.
>
> Jan
>
> Tuesday, March 19, 2024, 6:44:10 PM, you wro
First, lets consider the two usages you highlighted
1. In theory it is possible to add properties to a Logger. In practice, we only
allow this from the LoggerConfig. While the values of those properties can
include Lookup references this isn’t going to help much since there is no way
for the Lo
+1
Verified signatures
Verified hashes
Verified License and Notice files.
Note - the copyright year should be the first year the code was created. You
can update it to include “-(currentYear}” but that is not strictly necessary.
Ralph
> On Mar 4, 2024, at 10:48 AM, Jan Friedrich wrote:
>
>
> On Mar 4, 2024, at 6:24 AM, Piotr P. Karwasz wrote:
>
> There is a further simplification possible: since Oracle's extended
> support for Java 7 has expired in July 2022, shouldn't we also
> redirect the `2.3.x` and `2.12.x` websites to `2.x`?
Why would we do that? I mean we don’t officiall
> On Mar 1, 2024, at 6:55 AM, Piotr P. Karwasz wrote:
>
> Hi Piers,
>
> On Fri, 1 Mar 2024 at 14:14, Piers Uso Walter wrote:
>> Thanks for the quick response.
>> And yes, everything is OK on your side.
>>
>> I did indeed somehow manage to download the HTML file as the zip archive.
>> That e
Just navigate to https://archive.apache.org/dist/logging/ and take a look. Note
that under log4j you will find version directories. Under log4j-audit you will
not find directories. Basically it is however they get added to
https://dist.apache.org/repos/dist/dev/logging/. It is just a mirror of w
There could be if there was a StatusLogger per LoggerContext. But you would
still need a global StatusLogger. But doing that seems like overkill.
On the one hand it is very convenient to configure the level in the config
file, but on the other the fact that it only takes place halfway through
+1
Ralph
> On Feb 12, 2024, at 2:31 PM, Christian Grobmeier wrote:
>
> Hello,
>
> This vote is to put Chainsaw to the "Dormant" components. There is much work
> to be done on this component, but not enough hours can be committed to do
> that work. To reflect this situation to the user, it is
If Scott is +1 then let’s start a vote thread for this.
Ralph
> On Feb 7, 2024, at 8:56 AM, Robert Middleton wrote:
>
> +1
>
> While I agree that it can be useful, it was never really in a state
> where it is. I think it has a lot of good ideas, but to make it more
> modern and practical it n
When you say “hard to work with it” what does that mean? All that should ever
be required is to do
git rebase asf-staging
I have never had that take more than a few seconds.
Are you really saying that the staging site is hard to work with? My
understanding is that “we” are working on reworki
On 2024/02/05 15:17:29 Volkan Yazıcı wrote:
>
> AFAIK, nested logging is not a documented feature. Yet one can find several
> tickets people has filed issues that were fixed by us. Hence, it is safe to
> conclude that it is used.
You are correct that it is not documented. Nor should it be. As
> On Jan 29, 2024, at 12:35 PM, Piotr P. Karwasz
> wrote:
>
> Hi Andreas,
>
> On Mon, 29 Jan 2024 at 18:45, wrote:
>> Note, this happens even though effectively just two lines are really logged.
>> If DEBUG or TRACE were enabled in the loggers, then tens if not hundreds of
>> thousands of
1 - 100 of 1994 matches
Mail list logo
