[VOTE] Release Apache Log4cxx 1.4.0

[Stephen Webb]

This is a vote to release the Apache Log4cxx 1.4.0.

Website: https://logging.staged.apache.org/log4cxx/1.4.0/changelog.html
GitHub: https://github.com/apache/logging-log4cxx
Commit: cd328c32ace21a10f3e15838d776b89addded415
Distribution: https://dist.apache.org/repos/dist/dev/logging/log4cxx/
Signing key: 077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0
Review kit: 
https://github.com/apache/logging-log4cxx/blob/master/admin/release-review-instructions.md

Please download, test, and cast your votes on this mailing list.

[ ] +1, release the artifacts
[ ] -1, don't release, because ...

This vote is open for 72 hours and will pass unless getting a net
negative vote count.
All votes are welcome and we encourage everyone to test the release,
but only the
Logging Services PMC votes are officially counted.

Re: [log4cxx] bugfix release?

[Stephen Webb]

There is one significant feature (buffered seconds on file appender) so I
have made the next version 1.4.0

On Wed, 26 Feb 2025, 3:25 am Piotr P. Karwasz, 
wrote:

> Hi Tobias,
>
> On 23.02.2025 13:16, Tobias Frost wrote:
> > (Just an follow up, not sure if the previous mail went through anyways;
> > to make sure I'll CC Robert and Piotr, please feel free to forward the
> > mail if it didn't make it to the list)
>
> If you are not subscribed to the mailing list, your mails are moderated,
> so it takes a little bit longer.
>
> > Soft Freeze actually starts March 15th, and from this date on
> > "No large/disruptive changes" are no longer appropiate.
> > This could include a "new upstream release" 1.4.0, not sure if
> > you would categorize the chanes as "large" or "disruptive" (or
> > "risky" to break packages using log4cxx.)
>
> Robert, can we make it by March 15th? I didn't check in depth the recent
> commits, but they don't seem particularly disruptive, so it seems that
> the next version will be 1.3.2, right?
>
> Piotr
>

Re: Log4j-spring-boot is still required in Spring Boot 3

[Ralph Goers]

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 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.
> 
> IMHO the `Log4j2LoggingSystem` (both ours and the one in Spring Boot 3) has a 
> lot of aspects that can be improved:
> 
> 1. This `LoggingSystem` is enabled each time `log4j-core` is on the 
> classpath. It should also check that `log4j-core` has been selected as Log4j 
> API provider, otherwise many `ClassCastException`s will follow.
> 
> 2. Each time a `LoggerContext` is needed `LogManager.getContext(false)` is 
> called. This means that the logger context used by `initialize()` and 
> `cleanUp()` are not necessarily the same. Users have reported a couple of 
> times that `cleanUp()` will start a new logger context if the old one was 
> already closed. If `cleanUp()` is called during the JVM shutdown, the Log4j 
> API will return a `SimpleLoggerContext` and a `ClassCastException` will occur.
> 
> 3. Spring Boot apparently allows a different `LoggingSystem` per class loader 
> (it passes a class loader argument to the `LoggingSystemFactory`), but the 
> argument is not passed down to the Log4j API, so we can not use our 
> `ContextSelector` to create an appropriate context. One of the consequences 
> is that a Spring Boot application running in a Log4j Core-enabled Tomcat, 
> will try to modify to logger levels of a logger context shared by all the 
> apps on the server.
> 
> 4. The structured logging feature they implemented in version 3.4.x, totally 
> ignores all the work Volkan and others put into JTL. We can probably 
> reimplement it more efficiently by not trying to reinvent the wheel.
> 
> If you are interested, we could probably create a GitHub project and take 
> `Log4j2LoggingSystem` for a spin. If we end up with a better result, we can 
> push it back to Spring Boot or even bring it back to Log4j.
> 
> Piotr
> 

Re: [log4cxx] bugfix release?

[Piotr P. Karwasz]

Hi Tobias,

On 23.02.2025 13:16, Tobias Frost wrote:

(Just an follow up, not sure if the previous mail went through anyways;
to make sure I'll CC Robert and Piotr, please feel free to forward the
mail if it didn't make it to the list)


If you are not subscribed to the mailing list, your mails are moderated, 
so it takes a little bit longer.



Soft Freeze actually starts March 15th, and from this date on
"No large/disruptive changes" are no longer appropiate.
This could include a "new upstream release" 1.4.0, not sure if
you would categorize the chanes as "large" or "disruptive" (or
"risky" to break packages using log4cxx.)


Robert, can we make it by March 15th? I didn't check in depth the recent 
commits, but they don't seem particularly disruptive, so it seems that 
the next version will be 1.3.2, right?


Piotr

Re: Any updates on log4j 3.0.0 becoming GA?

[Daniel Burrell]

Hi logging team,

Perhaps if there are no further concerns, would it be possible for one of
the maintainers to please cut a release of log4j 3.0?

Kind regards

Daniel Burrell


On Wed, 29 Jan 2025 at 23:35, Daniel Burrell 
wrote:

> Dear Apache Logging team,
>
>
> We've been testing log4j beta3 with much success and appreciate the clear
> migration documentation, as well as support from ppkarwasz (thank you!).
>
>
> Could you provide any information about the expected timeline for the
> release of log4j 3.0.0 GA?
>
>
> Is this something we will see released in the near future or are there
> still outstanding issues preventing the release?
>
>
> Thank you for your continued work on this valuable project.
>
>
> Kind regards,
>
>
> Daniel Burrell
>

-- 
*This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you are not the named addressee you must not disseminate, distribute or 
copy this e-mail. Please notify us on regulat...@b2c2.net 
 immediately if you have received this e-mail 
by mistake and delete this e-mail from your system. If you are not the 
intended recipient you are notified that disclosing, copying, distributing 
or taking any action in reliance on the contents of this information is 
strictly prohibited.*

Log4j-spring-boot is still required in Spring Boot 3

[Ralph Goers]

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-projects/spring-boot/issues/44399.

I plan to create a PR for Spring Boot.

Re: Log4j-spring-boot is still required in Spring Boot 3

[Piotr P. Karwasz]

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


IMHO the `Log4j2LoggingSystem` (both ours and the one in Spring Boot 3) 
has a lot of aspects that can be improved:


1. This `LoggingSystem` is enabled each time `log4j-core` is on the 
classpath. It should also check that `log4j-core` has been selected as 
Log4j API provider, otherwise many `ClassCastException`s will follow.


2. Each time a `LoggerContext` is needed `LogManager.getContext(false)` 
is called. This means that the logger context used by `initialize()` and 
`cleanUp()` are not necessarily the same. Users have reported a couple 
of times that `cleanUp()` will start a new logger context if the old one 
was already closed. If `cleanUp()` is called during the JVM shutdown, 
the Log4j API will return a `SimpleLoggerContext` and a 
`ClassCastException` will occur.


3. Spring Boot apparently allows a different `LoggingSystem` per class 
loader (it passes a class loader argument to the 
`LoggingSystemFactory`), but the argument is not passed down to the 
Log4j API, so we can not use our `ContextSelector` to create an 
appropriate context. One of the consequences is that a Spring Boot 
application running in a Log4j Core-enabled Tomcat, will try to modify 
to logger levels of a logger context shared by all the apps on the server.


4. The structured logging feature they implemented in version 3.4.x, 
totally ignores all the work Volkan and others put into JTL. We can 
probably reimplement it more efficiently by not trying to reinvent the 
wheel.


If you are interested, we could probably create a GitHub project and 
take `Log4j2LoggingSystem` for a spin. If we end up with a better 
result, we can push it back to Spring Boot or even bring it back to Log4j.


Piotr