Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

And for main: https://github.com/apache/logging-log4j2/pull/2493 Gary On Thu, Apr 18, 2024 at 10:21 AM Gary D. Gregory wrote: > > TY for your help Piotr. > > The PR for the 2.x part is here > https://github.com/apache/logging-log4j2/pull/2486 > > Gary > > On 2024/04/18 02:58:39 "Gary D.

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

TY for your help Piotr. The PR for the 2.x part is here https://github.com/apache/logging-log4j2/pull/2486 Gary On 2024/04/18 02:58:39 "Gary D. Gregory" wrote: > Hi Piotr, > > Please see the branch feature/2.x/mongodb-next and its failing tests. > > TY, > Gary > > On 2024/04/17 21:59:45

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

Hi Piotr, Please see the branch feature/2.x/mongodb-next and its failing tests. TY, Gary On 2024/04/17 21:59:45 "Gary D. Gregory" wrote: > This is the plan that Piotr and I came up with one addition (1c): > > 1. Branch 2.x > 1.a. Drop module log4j-mongodb3 > 1.b. Add module log4j-mongodb (no

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

This is the plan that Piotr and I came up with one addition (1c): 1. Branch 2.x 1.a. Drop module log4j-mongodb3 1.b. Add module log4j-mongodb (no number) that contains one class that instantiates the log4j-mongodb4 provider. XML element is MongoDb. 1.c. Deprecate module log4j-mongodb4 in favor

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

Hi Gary, On Wed, 17 Apr 2024 at 21:23, Gary Gregory wrote: > But then your config has to say AND depend on the mongodb5 > module! Still confusing  There is actually a rarely used feature of our plugin system, where a plugin named `Foo` can actually create an object of type `Bar`. See for

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

But then your config has to say AND depend on the mongodb5 module! Still confusing  On Wed, Apr 17, 2024, 2:29 PM Piotr P. Karwasz wrote: > Hi Gary, > > On Wed, 17 Apr 2024 at 18:45, Gary Gregory wrote: > > Maybe if want to only use the latest driver for main, we should rename > the > >

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

Hi Gary, On Wed, 17 Apr 2024 at 18:45, Gary Gregory wrote: > Maybe if want to only use the latest driver for main, we should rename the > module and classes and drop the "4". That or go with what I initially > suggested. Your initial proposal of having a separate `log4j-mongodb4` and

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

Maybe if want to only use the latest driver for main, we should rename the module and classes and drop the "4". That or go with what I initially suggested. Gary On Wed, Apr 17, 2024, 12:18 PM Gary Gregory wrote: > Hi Piotr, > > Having mongodb4 module depend on the mongodb 5 driver sure is

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

Hi Piotr, Having mongodb4 module depend on the mongodb 5 driver sure is confusing though. What I don't know and don't want to deal with is "I updated to the latest log4j-mongdb5 version and my app no longer works" because it might turn out that the newer 5.x driver drops support for older Mongo

Re: [Log4j] In 2.x, drop log4j-mongodb3 and add log4j-mongodb5

Hi Gary, On Wed, 17 Apr 2024 at 16:36, Gary D. Gregory wrote: > > Hello All, > > In In 2.x, I would like to: > > - drop log4j-mongodb3 and > - add log4j-mongodb5 > - then do the same in 3.x > > Any objections? It is fine with me. Regarding log4j-mongodb5: MongoDB driver has already been

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

And thank you Volkan for walking me through fixing my local issue. Gary On 2024/03/06 16:22:50 Gary Gregory wrote: > The build was completed successfully. > > Gary > > On Wed, Mar 6, 2024 at 11:02 AM Gary Gregory wrote: > > > > I nuked the whole thing (rm -rf ~/.m2/repository/) for good

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

The build was completed successfully. Gary On Wed, Mar 6, 2024 at 11:02 AM Gary Gregory wrote: > > I nuked the whole thing (rm -rf ~/.m2/repository/) for good measure > (I'll do that once a month from now on). > > Building (and downloading the world)... > > It's made it past log4j-bom so we

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

I nuked the whole thing (rm -rf ~/.m2/repository/) for good measure (I'll do that once a month from now on). Building (and downloading the world)... It's made it past log4j-bom so we might be looking good... TY! Gary On Wed, Mar 6, 2024 at 10:33 AM Volkan Yazıcı wrote: > > Could you do `rm

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

Could you do `rm -rf ~/.m2/repository/org/apache/commons` and retry, please? (If you compare `target/bom.xml`s you can see that your local `commons-*` clones have different hashes.) On Wed, Mar 6, 2024 at 4:00 PM Gary Gregory wrote: > On Wed, Mar 6, 2024 at 9:54 AM Volkan Yazıcı wrote: > > > >

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

On Wed, Mar 6, 2024 at 9:54 AM Volkan Yazıcı wrote: > > Could you share the `target/bom.xml` and https://paste.apache.org/za0k3 > `target/log4j-bom-2.23.1.buildinfo` files too, please? https://paste.apache.org/1403q Gary > > On Wed, Mar 6, 2024 at 3:35 PM Gary Gregory wrote: > > > rm -rf

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

Could you share the `target/bom.xml` and `target/log4j-bom-2.23.1.buildinfo` files too, please? On Wed, Mar 6, 2024 at 3:35 PM Gary Gregory wrote: > rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1* > export NEXUS_REPO= >

Re: [log4j] `2.23.1` reproducibility failure (Was: [VOTE] Release Apache Log4j 2.23.1)

rm -rf ~/.m2/repository/org/apache/logging/log4j/*/2.23.1* export NEXUS_REPO=https://repository.apache.org/content/repositories/orgapachelogging-1261 sh mvnw -Prelease verify artifact:compare -Dreference.repo=$NEXUS_REPO Gary On Wed, Mar 6, 2024 at 9:33 AM Volkan Yazıcı wrote: > > Which

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

Hi Ralph, On Wed, 14 Feb 2024 at 04:35, Ralph Goers wrote: > To be honest, this isn’t a top priority on the list of things that need to be > addressed for me which is partly why I guess I am hesitant to do anything. It > feels like we keep talk about making changes but aren’t really focused on

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

I agree with your remark on priority. Using Log4j 2 API in Log4j 3 is indeed our focus. My recent refactoring of `StatusLogger` was a part of that effort. Since I already have my hands dirty with it, I want to take one last step to polish it in `main` and remove the `StatusConfiguration` wrinkle.

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: [log4j] Remove `` in `main`

If there were a way to allow for multiple StatusLogger configurations concurrently, then I’d support keeping it in the config file. Otherwise, I’m somewhat ambivalent about this. > On Feb 12, 2024, at 13:29, Volkan Yazıcı wrote: > > *Abstract:* I want to remove from `main` the feature that a

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

I’ve delayed answering because I can’t make up my mind. I am still thinking about this. Ralph > On Feb 12, 2024, at 12:58 PM, Piotr P. Karwasz > wrote: > > Hi Volkan, > >> On Mon, 12 Feb 2024 at 20:30, Volkan Yazıcı wrote: >> `StatusLogger` can be configured in following ways: >> >> 1.

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

Hi Volkan, On Mon, 12 Feb 2024 at 20:30, Volkan Yazıcı wrote: > `StatusLogger` can be configured in following ways: > >1. Passing system properties to the Java process (e.g., >`-Dlog4j2.StatusLogger.level=INFO`) >2. Providing properties in a `log4j2.StatusLogger.properties` file in >

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

Thanks so much for thinking along with me Piotr in this pretty sophisticated puzzler. Regarding your following statements... On Mon, Feb 5, 2024 at 8:43 PM Piotr P. Karwasz wrote: > I would prefer for the two event factories **not** to call > `Message#getFormattedMessage` at all. > ... > Both

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

Hi Volkan, On Mon, 5 Feb 2024 at 20:13, Volkan Yazıcı wrote: > What about the other two issues I mentioned: > >1. `log4j2.formatMsgAsync` and `@AsynchronouslyFormattable` don't always >work (`log4j2.formatMsgAsync=false` is ignored for reusable messages, which >are formatted always

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

Hi Volkan, On Mon, 5 Feb 2024 at 16:18, Volkan Yazıcı wrote: > I thought of matching the behavior between the two log event factories by > making the `DefaultLogEventFactory` format the message at creation. This > would imply both message factories will be formatting the message eagerly. >

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

Okay, nested logging is officially not supported. I will remove the nested logging tests blocking the `2.x-StatusLogger-revamp` branch. What about the other two issues I mentioned: 1. `log4j2.formatMsgAsync` and `@AsynchronouslyFormattable` don't always work (`log4j2.formatMsgAsync=false`

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

Aw: Re: [log4j] performance issue 2.22.1 vs. 2.22.0

Thank you both for the responses.   You asked for the log4j configuration. I try to extract the relevant parts.   Indeed the application has got a DynamicThresholdFilter in the game. There two appenders referenced from the loggers, one usual RollingFile appender

Re: [log4j] performance issue 2.22.1 vs. 2.22.0

Hi Ralph, On Mon, 29 Jan 2024 at 20:45, Ralph Goers wrote: > It is pretty obvious that the change you made has dire consequences. I don't dispute that. ;-) I just want to make sure it is the **only** thing that killed performance. As Andreas says, only a couple of events are logged. If the

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] performance issue 2.22.1 vs. 2.22.0

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 lines would be logged - so definitely, > there is a lot of logging going

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

Perhaps mention of StringBuilderFormattable? It helps work around the “load the string all at once” problem. > On Jan 26, 2024, at 06:36, Gary Gregory wrote: > > Oh, I don't want to suggest this is a Lo4j issue at all. I am wondering if > there is a pattern we should document aside from "know

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

Oh, I don't want to suggest this is a Lo4j issue at all. I am wondering if there is a pattern we should document aside from "know your third party objects" which is not helpful for us to say. It sounds like there is nothing for us to do. Gary On Fri, Jan 26, 2024, 7:16 AM Apache wrote: > That

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

That is kind of my point. Anyone who logs an object that behaves this way is asking for trouble. It really sounds like an esoteric edge case to me. I don’t view this as a Log4J problem as the error wouldn’t even have Log4J in the stack trace. Ralph > On Jan 25, 2024, at 9:52 PM, Gary Gregory

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

I have no control over this. I think this is a general problem with third party objects and toString(). There is no toString(fromHereToThere) or toStringReader() so I can't see a general way to deal with it. Even if I created a wrapper for the Object and called toString(), truncated and cached the

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

OK. The only good way to handle that is to parse the YAML/JSON file while streaming it and extract just the fields you want to include in the logs. Ralph > On Jan 25, 2024, at 6:40 PM, Gary Gregory wrote: > > Well, it's worse than that because the object is an object created by > parsing a

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

Well, it's worse than that because the object is an object created by 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

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] If and how to document potential OOME

*[Just responding to Matt. I don't have an answer for Gary.]* `JsonTemplateLayout` has `maxStringLength`, and related with it, `truncatedStringSuffix`. On Thu, Jan 25, 2024 at 9:45 PM Matt Sicker wrote: > You can use the %maxLength{…}{N} pattern converter with PatternLayout at > least.

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

You can use the %maxLength{…}{N} pattern converter with PatternLayout at least. Unfortunately, I don’t think any other layouts support a similar option. > On Jan 25, 2024, at 10:55, Gary D. Gregory wrote: > > Hi All, > > I'd like to ask how to if we can devise advice around an issue I ran

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

Obvious mistake: logger.debug("This is fun", myFunObject::toString) -> logger.debug("This is fun {}", myFunObject::toString) Gary On Thu, Jan 25, 2024, 11:55 AM Gary D. Gregory wrote: > Hi All, > > I'd like to ask how to if we can devise advice around an issue I ran into > this week. > > One

Re: [log4j] `flapdoodle-embed` minor update breaks MongoDB tests

Hi Volkan, On Tue, 23 Jan 2024 at 09:15, Volkan Yazıcı wrote: > > Gary, the following `flapdoodle-embed` minor updates breaks the MongoDB > tests. Would you mind helping us to fix them, please? > >1. Bump `flapdoodle-embed.version` from `4.9.0` to `4.10.2` in `2.x` ( >#2202

Re: [log4j] Bump default status logger level to WARN

I like this idea, Piotr. > On Jan 22, 2024, at 12:28 PM, Piotr P. Karwasz > wrote: > > Hi Volkan, > > On Mon, 22 Jan 2024 at 15:15, Volkan Yazıcı wrote: >> Shall we mention this issue (that is, ineffective configurations as the one >> you shared about `bufferSize`-vs-`bufferedIo`) to Łukasz

Re: [log4j] Bump default status logger level to WARN

Hi Volkan, On Mon, 22 Jan 2024 at 15:15, Volkan Yazıcı wrote: > Shall we mention this issue (that is, ineffective configurations as the one > you shared about `bufferSize`-vs-`bufferedIo`) to Łukasz and see if he > would be willing to carry out that clean up? ... granted PMC agrees to > raise

Re: [log4j] Bump default status logger level to WARN

I am in favor of reporting unrecognized/ignored properties, otherwise there is no incentive for users to fix their configurations. Those who don't want to be bothered with them, can still do so via `-Dlog4j.StatusLogger.level=off`. Shall we mention this issue (that is, ineffective configurations

Re: [log4j] Bump default status logger level to WARN

Hi Volkan, On Mon, 22 Jan 2024 at 13:31, Volkan Yazıcı wrote: > Piotr, could you share some examples of typical working configurations that > will start reporting errors? What kind of errors will these reports > contain? A message or a fully-blown stack trace? Will there be a multitude > of

Re: [log4j] Bump default status logger level to WARN

Piotr, could you share some examples of typical working configurations that will start reporting errors? What kind of errors will these reports contain? A message or a fully-blown stack trace? Will there be a multitude of these? Or 1-2 occasional appearances? I know answers will vary dependending

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. >> >> ? The contribution I made was done last year - long

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

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. > > ? The contribution I made was done last year - long past 2.7. Yes, what I meant is that Spring Boot uses some Log4j Core

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

I have a much more liberal view of the API. That is, if the class isn’t documented as private AND it can be reasonably used outside of Log4j then it is public. However, I would actually have to look at every class to see how much different it is from your list. Ralph > On Jan 18, 2024, at

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 in the spi or >> abstracted to

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

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.logging.log4j.spi.LoggerContext; > import org.apache.logging.log4j.spi.LoggerContextFactory; > import

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

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 in the spi or > abstracted to reference something in the spi. I am assuming a log4j-spi-2.x > would

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

Hi Volkan, On Wed, 17 Jan 2024 at 17:12, Volkan Yazıcı wrote: > Given Ralph and Piotr are strongly opinionated about keeping > `log4j-api-3.x` binary compatible to `log4j-api-2.x`, can we not release > `log4j-api-3.x` in `main` and make `main` only depend on `log4j-api-2.x` > instead? The main

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 non-API (`AbstractLogger`, `PropertiesUtil`, etc.) classes >>> in

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-spi-3.x` module, and >> 2. Only implement

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"

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'd love to hash this out in a call. Gary On Thu, Jan 18, 2024 at 12:02 AM Ralph Goers wrote: > > The quick answer to this question is “I don’t know”.

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

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 `log4j-core` we can have a Log4j 3 without a `log4j-api-3.x` module, right?

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”. When we

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] Making Log4j 2 API "the Log4j API"

That might work, yeah. > On Jan 17, 2024, at 12:46 PM, Volkan Yazıcı wrote: > > We can move the spi package content in main to a separate module in main. > SPI problem is solved? > > On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote: > >> I suspect this won’t work that well once I’ve

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

We can move the spi package content in main to a separate module in main. SPI problem is solved? On Wed, 17 Jan 2024 at 18:33, Matt Sicker wrote: > I suspect this won’t work that well once I’ve implemented > https://github.com/apache/logging-log4j2/issues/1977 as the current > provider SPI is

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

Or if we back port any of those changes I’ll propose, then perhaps we can continue with the API at 2.x. That does require that the API target Java 8, though. > On Jan 17, 2024, at 11:32 AM, Matt Sicker wrote: > > I suspect this won’t work that well once I’ve implemented >

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

I suspect this won’t work that well once I’ve implemented https://github.com/apache/logging-log4j2/issues/1977 as the current provider SPI is fairly lacking. It might make more sense to release the main API as 3.0.0 and have 2.x depend on the updated API. > On Jan 17, 2024, at 10:11 AM, Volkan

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 understand what it means to keep both staging and publish in >>> “asf-site”. By

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 branch is the live web-site and >>

Re: [log4j] Performance figures

Hi Remko! Just saying "Hi". Gary On Tue, Jan 16, 2024, 1:40 AM Remko Popma wrote: > I’m open to improvements in this area. > > Before going into details or specifics though, I’m curious: > > What do we (users, developers and PMC members) consider to be the “value > proposition” of Log4j? Why

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

Should these files contain comments to this effect? Gary On Tue, Jan 16, 2024, 1:18 AM 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

Re: [log4j] Performance figures

I’m open to improvements in this area. Before going into details or specifics though, I’m curious: What do we (users, developers and PMC members) consider to be the “value proposition” of Log4j? Why should people choose Log4j over the alternatives? This is a positioning question; what are

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

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 branch is the live web-site and > asf-staging is the staging web site. Are you talking about the build scripts > or

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: [log4j] `.asf.yaml` between branches

Even though it wouldn't be of my preference, keeping both `staging` and `publish` configuration in `asf-site` sounds like a middle ground I can live with. I will appreciate it if you can adapt your existing changes (in `logging-log4j-kotlin`, `logging-parent`, etc.) to comply with this, unless you

Re: [log4j] Performance figures

We should IMO keep this information available _somewhere_, maybe in a new stable historical-archival section of the site. I'm not a fan of using the wiki because that's yet another place to look for information and it feels transitory, unstable (as far as information permanance), and more like

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

Hi Volkan, On Mon, 15 Jan 2024 at 11:07, Volkan Yazıcı wrote: > > * you can stage the website for a release with a simple: > > > > git checkout asf-staging > > git reset --hard asf-site > > unzip ... > > git push -f > > > > You can do the same in the existing setup too. You just need a `sed` >

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

On Mon, Jan 15, 2024 at 9:45 AM Piotr P. Karwasz wrote: > This setup has some pros: > > * you don't need to navigate to all the website branches to see how > they are configured, > This would only work *iff* the `.asf.yaml` between the branch you are looking at (e.g., `main`) and the target

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

Hi Volkan, On Mon, 15 Jan 2024 at 09:28, Volkan Yazıcı wrote: > Piotr, I have seen you applied this *"sync'ing `asf.yaml` between branches"* > practice in `logging-parent` too. I find this new setup > >- *confusing* – Previously, say, `asf-site` related configuration was >only in the

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

It feels wrong to add support for a special development time tool in our runtime. Gary On Thu, Jan 11, 2024, 1:58 PM Ralph Goers wrote: > 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

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: [log4j] Revamping Log4j website & manual tooling

On Wed, Dec 20, 2023 at 10:56 PM Christian Grobmeier wrote: > We = you & Piotr? I was surprised to find out you were having a meeting > for a milestone that also included me. > It wasn't a meeting, but a casual unplanned brain-storming session, which we do several times every day with Piotr. I

Re: Log4j 2.22.1 release schedule

The plan sounds good to me. I am only not comfortable with the workaround to #2065 . In a nutshell, the way Coursier/Ivy derives the effective POM doesn't match the one Maven does. Only to make Coursier/Ivy work, we add redundant dependency

Re: [log4j] Revamping Log4j website & manual tooling

On Wed, Dec 20, 2023, at 17:50, Volkan Yazıcı wrote: > On Wed, Dec 20, 2023 at 5:05 PM Christian Grobmeier > wrote: > >> I see only one mention of Antora, the tool you are proposing. > > > I am indeed **not** proposing Antora (removed its mentions), but plain > AsciiDoc, which is exactly what we

Re: [log4j] Revamping Log4j website & manual tooling

On Wed, Dec 20, 2023 at 5:05 PM Christian Grobmeier wrote: > I see only one mention of Antora, the tool you are proposing. I am indeed **not** proposing Antora (removed its mentions), but plain AsciiDoc, which is exactly what we have in Log4j, Log4j Kotlin, Log4j Scala, Log4j Tools, Log4j

Re: [log4j] Revamping Log4j website & manual tooling

I see only one mention of Antora, the tool you are proposing. You don't have to sell us Asciidoc; we all have our opinions about it; the majority of the document is about "why not" but little "why Antora" I would be more interested in the challenges/benefits of Antora, and how such a system

Re: [log4j] Revamping Log4j website & manual structure

*[We can indeed discuss this further in the video call.]* If I am not mistaken, you were a big fan of PostgreSQL's website – correct me if I am wrong. The current structure is pretty much analogous to what they have: a set of common pages (about, support, tutorials, etc.) and

Re: [log4j] Revamping Log4j website & manual structure

Hi all, Thank you V for putting this together. >From a high level, I don't like that the proposal is split into a website and a manual. The material should be the same and obviously optionally differently as a site vs a manual. For example, why is the tutorial excluded from the manual? Anyway,

Re: [log4j-kotlin] Next release (`1.3.1`-vs-`1.4.0`)

Thanks Volkan -- Matt, I believe release 1.4.0 is ready for a vote. * ASF staging site: https://logging.staged.apache.org/log4j/kotlin/latest/#release-notes-1-4-0 (from branch https://github.com/apache/logging-log4j-kotlin/commits/asf-staging/) * Signed distribution and checksums:

Re: [log4j] Revamping Log4j website & manual

When I read "pages", "site", and do on, I am reminded of the model-view paradigm. I would offer that we focus on _content_ first, and write that content in some general format that tooling can then be used to generate a site, a PDF, Javadoc, whatever. FWIW, when I worked on the "Java Persistence

Re: [log4j] Revamping Log4j website & manual

I’d be interesting in helping with this, particularly around plugin development docs which are somewhat anemic. I’ve got several things to document in a non-API-doc fashion from the new DI system and such, too. > On Dec 18, 2023, at 1:13 PM, Volkan Yazıcı wrote: > > *TLDR:* Log4j websites &

Re: [log4j-kotlin] Next release (`1.3.1`-vs-`1.4.0`)

Thanks for the prompt action.  I will review the PR. Please keep in mind that you don't have sufficient rights to complete a release. A PMC member should volunteer as an RM (Release Manager), who, in your case, is Matt, I presume. That is, you can perform the git chores, but it is Matt who

Re: [log4j-kotlin] Next release (`1.3.1`-vs-`1.4.0`)

Thanks for the feedback Volkan. The PR with all of these changes is: https://github.com/apache/logging-log4j-kotlin/pull/56 Regards, Raman On Thu, Dec 7, 2023 at 5:54 AM Volkan Yazıcı wrote: > Raman, Matt, great that you want to release the next version of the Log4j > Kotlin! Thanks for your

Re: [log4j-kotlin] Next release (`1.3.1`-vs-`1.4.0`)

Thanks for the info! I don’t think you’re being pedantic here; the uniform release process is very important to keeping all our components healthy. > On Dec 7, 2023, at 4:54 AM, Volkan Yazıcı wrote: > > Raman, Matt, great that you want to release the next version of the Log4j > Kotlin! Thanks

Re: [log4j] Is `bnd` a curse or a blessing?

The optional bit I hope can be solved by refactoring Maven modules to have zero optional dependencies. Gary On Thu, Dec 7, 2023, 10:32 AM Piotr P. Karwasz wrote: > Hi Gary, > > On Thu, 7 Dec 2023 at 15:46, Gary Gregory wrote: > > > > Note that there is also the Maven moditect plugin but I

Re: [log4j] Is `bnd` a curse or a blessing?

As I stated, I like `bnd` and am glad to see that its 7.x version will help us lose some extra weight. And indeed we can fix some shortcomings I have mentioned. Though my points still stand: 1. We need extensive tweaking 2. It doesn't always blend well (IDEs, `spring-boot:repackage`, etc.)

Re: [log4j] Is `bnd` a curse or a blessing?

Hi Gary, On Thu, 7 Dec 2023 at 15:46, Gary Gregory wrote: > > Note that there is also the Maven moditect plugin but I don't know if it > deals with OSGi which brings up the issue of how much we should care about > OSGi (I don't know). We can disable JPMS descriptor generation in BND and switch

Re: [log4j] Is `bnd` a curse or a blessing?

Hi Volkan, I have supplied a PR to generate the service descriptors before Unit tests, but keep the module-info.class only in the JAR: https://github.com/apache/logging-parent/pull/75 On Thu, 7 Dec 2023 at 15:41, Volkan Yazıcı wrote: > *Bad: Programmatic configuration is not enough* > > We

Re: [log4j] Is `bnd` a curse or a blessing?

Note that there is also the Maven moditect plugin but I don't know if it deals with OSGi which brings up the issue of how much we should care about OSGi (I don't know). Gary On Thu, Dec 7, 2023, 9:41 AM Volkan Yazıcı wrote: > We use `bnd`, in particular, `bnd-maven-plugin` > < >

  1   2   3   4   5   6   7   8   9   10   >