Re: Author lines in documentation

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

Re: Canonicalization of URLs on our website

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

Re: Canonicalization of URLs on our website

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`

Re: Closing inactive issues

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

Re: Canonicalization of URLs on our website

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

Re: End-of-life date for `log4j-1.2-api`

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

Re: Context data propagation and logger-bound context data

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

Re: Should Log4j API bridges have a 3.x release?

> 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

Re: Should Log4j API bridges have a 3.x release?

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.

Re: End-of-life date for `log4j-1.2-api`

> 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

Re: Context data propagation and logger-bound context data

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

Re: Context data propagation and logger-bound context data

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

Re: Context data propagation and logger-bound context data

> 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

Re: Context data propagation and logger-bound context data

> 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

Re: Context data propagation and logger-bound context data

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 Tue, Mar 19, 2024 at 7:45

Re: Context data propagation and logger-bound context data

> 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

Re: Context data propagation and logger-bound context data

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

Re: Please update Flume DOAP

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

Re: Context data propagation and logger-bound context data

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

Re: [VOTE] Release Apache Log4net 2.0.16

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

Re: Removal of 2.3.x and 2.12.x websites (was: Clean site repo)

> 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

Re: Checksum of release 2.23.0 does not seem to be correct

> 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

Re: Distribution location was: [VOTE] Release Apache Log4j 3.0.0-beta2 RC1

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

Re: [log4j] Remove `` in `main`

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

Re: [VOTE] Move Chainsaw to dormant

+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

Re: [chainsaw] Status change?

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

Re: Clean site repo

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

Re: [log4j] Nested logging and async. message formatting

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

Re: [log4j] performance issue 2.22.1 vs. 2.22.0

> 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

Re: [Log4j] If and how to document potential OOME

> parsing a YAML (or JSON) file, then the toString() of that object > renders a String in some other format. > > Gary > > On Thu, Jan 25, 2024 at 7:45 PM Ralph Goers > wrote: >> >> Volkan & Matt, >> >> Neither of those is going to help. The iss

Re: [Log4j] If and how to document potential OOME

Volkan & Matt, Neither of those is going to help. The issue is that when the toString method is called it reads a whole file in and stores it as a String. This could cause the OOM error. Truncating it in a layout simply limits how much of the String is printed. Even Gary’s proposal of calling

Re: [log4j] Making Log4j 2 API "the Log4j API"

> On Jan 18, 2024, at 12:59 PM, Piotr P. Karwasz > wrote: > > Hi Ralph, > > On Thu, 18 Jan 2024 at 18:18, Ralph Goers wrote: >>> Besides we already broke their code, when 2.7 introduced breaking >>> changes to ConfigurationFactory. >> >> ? T

Re: [log4j] Making Log4j 2 API "the Log4j API"

t 9:25 AM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Thu, 18 Jan 2024 at 16:15, Ralph Goers wrote: >> Note that LogManager has >> >> import org.apache.logging.log4j.simple.SimpleLoggerContextFactory; >> import org.apache.log

Re: [log4j] Making Log4j 2 API "the Log4j API"

> On Jan 18, 2024, at 9:01 AM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Thu, 18 Jan 2024 at 15:56, Ralph Goers wrote: >> Spring uses PropertiesUtil. I suspect it isn’t alone. That would mean >> anything impacted by the property changes would have to be i

Re: [log4j] Making Log4j 2 API "the Log4j API"

> On Jan 18, 2024, at 8:14 AM, Ralph Goers wrote: > > > >> On Jan 18, 2024, at 7:55 AM, Ralph Goers wrote: >> >> >> >>> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı wrote: >>> >>> If we >>> >>> 1. move all

Re: [log4j] Making Log4j 2 API "the Log4j API"

> On Jan 18, 2024, at 7:55 AM, Ralph Goers wrote: > > > >> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı wrote: >> >> If we >> >> 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes >> in `log4j-api-3.x` to a new `log4j-s

Re: [log4j] Making Log4j 2 API "the Log4j API"

> On Jan 18, 2024, at 5:37 AM, Volkan Yazıcı wrote: > > If we > > 1. move all non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes > in `log4j-api-3.x` to a new `log4j-spi-3.x` module, and > 2. Only implement `log4j-api-2.x` *interfaces* (not abstract classes!) > in

Re: [log4j] Making Log4j 2 API "the Log4j API"

> On Jan 18, 2024, at 6:15 AM, Gary Gregory wrote: > > Using the same API jar for 3.x core is intriguing. I like the idea of > a cleaned-up API jar (no custom Supplier) that can front 2.x and 3.x. > I don’t think that is what Volkan is proposing as it definitely would break compatibility

Re: [log4j] Making Log4j 2 API "the Log4j API"

Now that I have had 10 seconds to think about it. The change to the property syntax and how PropertiesUtil works will create serious problems for what you are proposing. Ralph > On Jan 17, 2024, at 10:02 PM, Ralph Goers wrote: > > The quick answer to this question is “I don’t know”

Re: [log4j] Making Log4j 2 API "the Log4j API"

I am afraid I don’t really understand that. How does moving the spine content to another module help? Doesn’t that mean users would now need log4j-api-2.x.jar and log4j-spi-3,x,jar? What is the benefit of that? Ralph > On Jan 17, 2024, at 12:09 PM, Matt Sicker wrote: > > That might work,

Re: [log4j] Making Log4j 2 API "the Log4j API"

The quick answer to this question is “I don’t know”. When we first started on the 3.x adventure I can assure you that log4j-api was very different in the 3.x branch because of the changes we needed to make for JPMS and to the build. However, since we have since carried those changes back to 2.x

Re: [log4j] `.asf.yaml` between branches

> On Jan 16, 2024, at 9:15 AM, Ralph Goers wrote: > > > >> On Jan 15, 2024, at 11:18 PM, Piotr P. Karwasz >> wrote: >> >> Hi Ralph, >> >> On Tue, 16 Jan 2024 at 01:56, Ralph Goers wrote: >>> >>> I don’t understan

Re: [log4j] `.asf.yaml` between branches

> On Jan 15, 2024, at 11:18 PM, Piotr P. Karwasz > wrote: > > Hi Ralph, > > On Tue, 16 Jan 2024 at 01:56, Ralph Goers wrote: >> >> I don’t understand what it means to keep both staging and publish in >> “asf-site”. By definition, the asf-site bra

Re: Should we keep `log4j-appserver` and `log4j-jcl` in 3.x?

I am OK with this. It would be best if we could get Tomcat to publish a tomcat-log4j artifact. Ralph > On Jan 15, 2024, at 1:50 PM, Piotr P. Karwasz wrote: > > Hi all, > > While 3.x is approaching its first stable release as a meteor burning > through the sky, its core is getting smaller as

Re: [log4j] `.asf.yaml` between branches

I don’t understand what it means to keep both staging and publish in “asf-site”. By definition, the asf-site branch is the live web-site and asf-staging is the staging web site. Are you talking about the build scripts or something? I started to reply to this earlier today but got sidetracked

Re: Spring 3 and Log4j 3

On 2024/01/10 09:27:22 Volkan Yazıcı wrote: > Thanks for chasing this Ralph, it is indeed a nice step forwards. > > The aforementioned Log4j issue is fixed in #2062 > : > >1. You submitted the PR on Dec 5 at 04:15 (GMT+1) and merged it

Re: [log4j] ProGuard support in `log4j-api`

Yeah - if we add it to the code base that implies that we are testing it. I really don’t want to be in the position where we start adding customizations for every tool a user might be using. This is very much in line with our not wanting to keep adding more and more integrations . Ralph > On

Re: Removal of `log4j-jcl` in `3.x`

Fine by me. Ralph > On Jan 10, 2024, at 3:11 PM, Piotr P. Karwasz wrote: > > Hi all, > > Since `commons-logging` 1.3.0 was published last month and it supports > Log4j API out-of-the-box, does it still make sense to keep `log4j-jcl` > around in 3.x? > > I would keep the 2.x version, so that

Re: Spring 3 and Log4j 3

> On Jan 10, 2024, at 11:29 AM, Piotr P. Karwasz > wrote: > > Hi Matt, > > On Wed, 10 Jan 2024 at 18:45, Matt Sicker wrote: >> >> This might affect 2.x, though it’s largely in the Spring environment >> property source. Given the application lifecycle there, Spring doesn’t seem >> to

Spring 3 and Log4j 3

FYI - in https://github.com/spring-projects/spring-boot/issues/33450#issuecomment-1883014368 has confirmed that Log4j 3.0.0-beta1 now works correctly with Spring 3.x. Ralph

Re: PropertyKey abstraction

PropertyKey was created so that all “components” could be specified as an enum value, thus ensuring consistency. The split between component and key is used in every declaration of a property. It is unfortunate that the keys also had to be specified as static constants so they could be used

Re: `a.o.l.l.core.parser` package removal

since the fields are usually already available as headers. Ralph > On Jan 2, 2024, at 3:30 PM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Tue, 2 Jan 2024 at 13:21, Ralph Goers wrote: >> >> Why is it included if it isn’t used? > > Apparently thi

Re: `a.o.l.l.core.parser` package removal

Why is it included if it isn’t used? Ralph > On Jan 2, 2024, at 4:09 AM, Piotr P. Karwasz wrote: > > Hi, > > While working on PR#2142[1] I noticed that we have an > `a.o.l.l.core.parser` package that depends on Jackson. > > Since Log4j itself never parses log events, I would propose to

Re: [VOTE] Release Apache Log4j 3.0.0-beta1 (RC2)

+1 from me. Everything seems ok. Ralph > On Dec 19, 2023, at 2:00 PM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j 3.0.0-beta1 RC2. > > Website: https://logging.staged.apache.org/log4j/3.x > GitHub: https://github.com/apache/logging-log4j2 > Commit:

Re: [VOTE] Release Apache Log4j 3.0.0-beta1

Christian, The vote has been open for 6 days because we were under the impression the vote was going be cancelled based on Piotr’s feedback. I can commit to having the review done in 72 hrs if the release is cut today or tomorrow. This slow down for me at work this time of the year so between

Re: Versioning scheme

Maybe you could add comments to the schema to define what the enumerations are intended for and what effect they have on the release? Ralph > On Dec 12, 2023, at 10:13 AM, Volkan Yazıcı wrote: > > Got it. I will land a log4j-changelog change accordingly, implement the CI > magic, and update

Re: Versioning scheme

Yes. Ralph > On Dec 12, 2023, at 9:03 AM, Volkan Yazıcı wrote: > > Ralph, do you mean if all changes are a subset of bug fixes, deprecations, > or updates, then it is a patch release? > > On Tue, 12 Dec 2023 at 16:23, Ralph Goers > wrote: > >> I have to agre

Re: Versioning scheme

> On Dec 11, 2023, at 2:32 PM, Piotr P. Karwasz wrote: > > I propose to keep the old strategy: after a release we set the version > number to the next patch release. > Only if we merge a change that requires a minor bump (we can tag > those), we bump the release to the next minor version.

Re: Versioning scheme

I have to agree with Piotr’s example. Simply upgrading a dependency doesn’t, on its own, change any code in Log4j. I see three possible solutions for this: 1. Do not allow any dependency updates until a “scheduled” mentor release (once every 2 or 3 months). Frankly I’d be fine with this except

Re: Versioning scheme

The rule for this seems extremely simple to me. The changelog uses

Re: [flume] Website upgrade? (building the current site fails)

> On Dec 9, 2023, at 3:27 PM, Christian Grobmeier wrote: > > > On Sat, Dec 9, 2023, at 17:30, Ralph Goers wrote: >> Did you follow the instructions at >> https://cwiki.apache.org/confluence/display/FLUME/Updating+the+Web+Site? >> I don’t know why it would be us

Re: [flume] Website upgrade? (building the current site fails)

Obviously, I have never had a problem building the Flume web site, although I haven’t done it since the last release. I just ran the build with no problems. Did you follow the instructions at https://cwiki.apache.org/confluence/display/FLUME/Updating+the+Web+Site? I don’t know why it would be

Re: Future release schedule

Even though you probably all know, just for clarity our policy has been that every release is a patch release until it isn’t. That is, as soon as something other than a bug fix is added it becomes a minor release. Personally, I think this still makes sense as it avoids needing the extra branch.

Re: Logstash and Filebeat guaranteed delivery

Logstash) > I want to learn where I can potentially violate the delivery guarantee. > > On Thu, Nov 30, 2023 at 5:54 AM Ralph Goers > wrote: > Fluentbit, Fluentd, Logstash, and Filebeat are the main tools used for log > forwarding. While they all have some amount of pluga

Re: [Flume] Integration with OpenTelemetry

This is a great post Matt! Fluentbit, Fluentd, Logstash, and Filebeat are the main tools used for log forwarding. While they all have some amount of plugability none of the are as flexible as Flume. In addition, as I have mentioned before, none of them provide guaranteed delivery so I would

Re: Optional dependencies and JPMS

a user having to add a requires statement to their module-info file. Ralph > On Nov 29, 2023, at 7:29 AM, Ralph Goers wrote: > > I agree with this. IMO the only configuration syntaxes we should support are > those we can implement with no dependencies. At the moment that is JSON and

Re: Optional dependencies and JPMS

I agree with this. IMO the only configuration syntaxes we should support are those we can implement with no dependencies. At the moment that is JSON and Properties (Ugh!). I would love to deprecate properties but I know that is a non-starter since we didn’t support them for years and were

Re: [log4j] Releasing Log4j `3.0.0`

I do not understand what my email provider has against Volkan. Once again I did not receive his email. Looking at the archive I see you want to release 3.0.0 in February. That may be possible but that isn’t exactly what was discussed in the last video meeting we had. The meeting notes are at

Re: [log4j] Releasing Log4j `3.0.0`

> On Nov 28, 2023, at 7:21 AM, Gary Gregory wrote: > > I'm OK with either direction for merges for anything between 2.x and 3.x > branches for now and certainly until 3.x makes it out as a release. I won't > argue for or against either. > > As a semi aside, in Commons, I circumvented the

Re: [log4j] Unstable tests on Windows

I would be -1 if the issues are going to be ignored or not tracked in any way. I don’t know if GitHub has something like a Jira Epic or if they can be tagged in some way so that they can be easily located but something like that would be fine. Even tracking them in Confluence would be fine.

Re: Disable new issues in JIRA

We should NOT be creating new Jira issues. But locking down Jira completely would mean we would have to somehow transfer any active issues to GitHub. When that happens I would expect the Jira issue to link to the GitHub issue and vice versa as I would not expect all the Jira content and history

Re: [log4j] Unstable tests on Windows

Gary uses Windows as his development OS. He is probably the only one of us who does. So he inevitably finds these issues before the rest of us. I don’t know if the CI has a build that runs on Windows for every commit. Ralph > On Nov 20, 2023, at 6:12 AM, Robert Middleton wrote: > > Are the

Re: OSGi package versioning

API won’t work with an implementation that only supports 2.6.0. Ralph > On Nov 13, 2023, at 3:02 PM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Mon, 13 Nov 2023 at 22:18, Ralph Goers wrote: >> >> How does this relate, if at all, to the COMPATIBLE_API_VE

Re: OSGi package versioning

How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant defined in ProviderUtil.java? We use that to ensure the API only binds with a compatible implementation of the API. Ralph > On Nov 13, 2023, at 1:29 PM, Piotr P. Karwasz wrote: > > Hi all, > > As you probably noticed,

Re: [log4j] `2.22.0` release

That is OK with me. T Ralph > On Nov 13, 2023, at 7:22 AM, Volkan Yazıcı wrote: > > I would like to do the Log4j `2.22.0` release in a couple of days; > there are some bug fixes and SBOM is ready to be shipped. Let me know > if you have objections.

Re: [RESULT] [VOTE] Deprecation of 2.x modules/features and removal in 3.x

on this mailing list: >> >> [ ] +1, drop the artifact/module, >> [ ] +/-0 >> [ ] -1, keep the artifact/module, because... > > The following PMC have expressed their votes: Gary Gregory, Christian > Grobmeier, Matt Sicker, Ralph Goers, Volkan Yazıcı and me. >

Re: [log4j] What is JPMS support and its state

You know, I almost didn’t want to answer this email because after reading the text it was quite obvious to me that the question you are really trying to ask is: “What more needs to be done to kill off 3.x?” That being said I will still answer your question. First, I will say that the work to

Re: Features for 3.x was: Why is JNDI still necessary?

> On Nov 6, 2023, at 2:37 AM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Sun, 5 Nov 2023 at 05:39, Ralph Goers wrote: >> If we have changes in 2.x that are not in 3.x they aren’t many and we will >> never find that out without releasing. In general users d

Re: Features for 3.x was: Why is JNDI still necessary?

> On Nov 5, 2023, at 2:58 PM, Matt Sicker wrote: > I’ve suggested that we annotate code around API compatibility guarantees, and > we are using @InternalApi in main to mark things that shouldn’t be used as > stable code (even if it’s unlikely to change over time). > Please be careful of

Re: (logging-log4j2) branch 2.x updated: Backport Lazy util

Matt, I received 3 emails regarding this lazy stuff being back ported. Is there a related issue for this? With the volume of emails I am getting I may have missed it but I would like to understand, Furthermore, in none of these commit emails did I see a changes file listed? How can I know why

Re: Features for 3.x was: Why is JNDI still necessary?

> On Nov 3, 2023, at 10:08 PM, Christian Grobmeier wrote: > > >> However, like myself, organizations are not going to delay upgrading >> too long. Having Log4j 3.x be available before the majority of orgs >> switch to Spring 3 will greatly improve its adoption. > > Agreed, the earlier, so

Re: Features for 3.x was: Why is JNDI still necessary?

> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier wrote: > > On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote: >>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier >>> wrote: >>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote: >>>> Log4j

Re: Features for 3.x was: Why is JNDI still necessary?

> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier wrote: > > > > On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote: >> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java >> 17 seems to me as well a good thing. >> >> Gary &g

Re: [Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

be generalized to handle all 3, but that may be asking too much. Ralph > On Nov 2, 2023, at 8:43 AM, Volkan Yazıcı wrote: > > On Thu, Nov 2, 2023 at 4:04 PM Ralph Goers > wrote: > >>> On Nov 2, 2023, at 7:42 AM, Gary Gregory wrote: >>> On Mon, Oct 30,

[Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

Gary, As a reminder, a +1 vote means that the component will be marked deprecated in 2.x and removed in 3.x. This seems appropriate for log4j-spring-boot as users of Spring upgrading to Log4j 3.x will almost surely be on Spring Boot 3. Ralph > On Nov 2, 2023, at 8:55 AM, Piotr P. Karwasz

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

+1 to this change. Ralph > On Nov 2, 2023, at 8:16 AM, Volkan Yazıcı wrote: > > I deleted all date parsing functionality in Log4j[1] and the compilation... > [drum roll...] succeeded. I am inclined to commit this breaking change. We > can refer users who were previously using Log4j to parse

[Discuss]: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

Gary, a couple of comments: 1. I don’t understand what “there is no official JDBC access” has to do with Cassandra or CouchDB. Could you please elaborate? 2. The functionality in log4j-spring-boot is directly incorporated into Spring 3 due to a PR I submitted. So with Spring Boot 3

Re: Features for 3.x was: Why is JNDI still necessary?

I should add that I am concerned that we are missing a huge opportunity with Spring 3. A lot of folks will start their migration to Spring 3 early next year. Tying Log4J 3.x to that is a big opportunity for people to upgrade at the same time. Ralph > On Nov 2, 2023, at 3:53 AM, Ralph Go

Re: Features for 3.x was: Why is JNDI still necessary?

Piotr, I haven’t committed much to 3.x since June because it already has everything I set out to do. It is everyone else who keeps adding crap that “must” be done before it can be released. Yet another year is far too long. If that is the case my vote is to skip the additional stuff. And I will

Java version usage

As a follow up to Christian’s question, here are the usage statistics I could find for the Java LTS versions Java 8Java 11. Java 17 33& 56%9%.[1] 31% 28%. 19%. [2] Unfortunately, Jetbrains has not published a report for

Re: Why is JNDI still necessary?

> On Nov 1, 2023, at 9:24 PM, Christian Grobmeier wrote: > > > > On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote: >> Christian, I was at least 3 years ahead of you on this one.This is > > Sorry I was not active for a while. Good you were here. > >&g

Re: [LOG4J2-3672] Time zone parsing in `FastDateParser`

> On Nov 1, 2023, at 3:33 PM, Piotr P. Karwasz wrote: > > Hi Volkan, > > On Wed, 1 Nov 2023 at 12:07, Volkan Yazıcı wrote: >> Curious: *In the context of logging, does `FastDateParser` need to be fast >> while parsing?* We certainly need to *"format"* the instant fast. Though do >> we

Re: [Log4j] Main website page

t; https://github.com/apache/logging-log4j2/commit/96eb0d00099b709663a251484f2967cbb93b0230 >> >> On Wed, Nov 1, 2023 at 5:23 PM Ralph Goers >> wrote: >> >>> The Log4j site or the Logging site? Where can we review this? >>> >>> Ralph >>

Re: Why is JNDI still necessary?

n the PR/commit is attempted from >>> whomever gave the -1 vote. In other words, this is NOT a procedural vote >>> but a code modification vote that is taking place before the code is >>> modified. >>> >>> Ralph >>> >>>> On N

Re: [Log4j] Main website page

The Log4j site or the Logging site? Where can we review this? Ralph > On Nov 1, 2023, at 9:07 AM, Volkan Yazıcı wrote: > > Heads up! I have updated the main website page: removed the clutter, added > quick navigation links, and rewrote the pitch for features.

Re: [log4net] Project state

Gary is correct on this. In the past we have broken out the sub-projects under the project activity section and project health sections. You can see that in your own previous reports (and those from Matt and myself). Ralph > On Nov 1, 2023, at 5:48 AM, Gary Gregory wrote: > > Not quite IMO,

Re: [Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

Rats. In my first sentence replace “modules” with “repos”. Ralph > On Oct 31, 2023, at 3:53 PM, Ralph Goers wrote: > > Christian, > > Deprecation and moving to separate modules are not the same thing at all. I > would be +1 to moving everything on this list that isn’

Re: Why is JNDI still necessary?

There is a difference between a JEE application that only uses servlets vs one that uses EJBs. At a former employer we often used JBoss to run servlets even though we had no EJBs. In an environment with EJBs I am not sure how you can distinguish the various components from each other without

[Discuss][VOTE] Deprecation of 2.x modules/features and removal in 3.x

Christian, Deprecation and moving to separate modules are not the same thing at all. I would be +1 to moving everything on this list that isn’t outright removed to separate repos. I have stated that several times. Gary is strongly against doing that. If you are somehow equating deprecation

Re: [VOTE] Deprecation of 2.x modules/features and removal in 3.x

Here are my votes: > On Oct 30, 2023, at 1:44 AM, Piotr P. Karwasz wrote: > > This is a vote to deprecate the following `2.x` modules and features > and remove them from the `3.x` release: > > * `log4j-cassandra`: +1 > * CouchDB appender: +1 > * `log4j-docker` -1 - Still useful and supportable

  1   2   3   4   5   6   7   8   9   10   >