Re: Wrapped exceptions

[Piotr P. Karwasz]

Hi Ralph,

On Thu, 4 Apr 2024 at 21:01, Ralph Goers  wrote:
> I really have no idea why but this is the first time I have heard someone ask 
> for the ability to filter based on the Exception class.

This came out at least once before: see the SO "Log4j - How to log
specific exception into a separate file?" question[1].

There is a sample code in the answer to that question, feel free to
make a PR out of it.

Piotr

[1] https://stackoverflow.com/q/76919416/11748454

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: log4j initialization does not seem to happen when Tomcat service is started

[Piotr P. Karwasz]

Hi Piers,

On Sun, 31 Mar 2024 at 22:37, Piers Uso Walter  wrote:
>
> Thad,
>
>
> Thanks so much. This looks exactly what I want to do.
> But somehow I never got your code to work.
>
> ...
>
> I made these changes to your code:
>
> 1.
> LogListener is now a subclass of Log4jServletContextListener, instead of just 
> implementing ServletContextListener.
> So I’m only declaring a single listener in web.xml.
>
> 2.
> I’m not using the servlet init parameter 
> Log4jWebSupport.LOG4J_CONFIG_LOCATION to set the config file location.
> Instead, I’m initializing a log4j Configurator from the file.

Consider also setting the servlet init parameter
`isLog4jAutoInitializationDisabled` to `true` to disable the servlet
container initializer.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: log4j initialization does not seem to happen when Tomcat service is started

[Piotr P. Karwasz]

Hi Piers,

On Wed, 20 Mar 2024 at 17:09, Piers Uso Walter  wrote:
> Am I trying something unusual here when I attempt to make the app decide 
> where the log4j configuration file is located?
> Is there any other way in which I can achieve this?
> Is there an API for this?

Sorry for the late answer.

There are two solutions I could think of:

1. You could use a custom system variable (e.g.
`ilink.log4j2.configurationFile` and place:


log4jConfiguration

${sys:ilink.log4j2.configurationFile:-classpath:path_to_default_config_file


2. You could write container specific documentation:

* Tomcat supports the possibility to override context parameters
in an appropriate `context.xml` file:
https://tomcat.apache.org/tomcat-9.0-doc/config/index.html
* I don't have too much experiance with JBoss, but it supports
variable substitution in web descriptors and you could use a
`jboss-web.xml` file to prevent Tomcat from using it.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j2 migration issue

[Piotr P. Karwasz]

Hi Jasmine,

On Thu, 28 Mar 2024 at 12:12, JASMINE DASH  wrote:
> Please find the below log4j2.properties file.
>
> rootLogger.level = INFO, STDOUT appender = Console
> appender.console.name = STDOUT
> appender.console.type = Console appender.console.layout.type = PatternLayout
>
> appender.console.layout.pattern = %5p [%t] %C{1}.%M() [%L] -> %m%
>
> rootLogger.appenderRef.stdout.ref = STDOUT

Your value of the `rootLogger.level` property is invalid, it should
only contain the name of a level like `INFO`. The `appender` property
has no meaning, so you can remove it.

Anyway you should rather use the XML format. An example almost
identical to your configuration is available on our XML schema page:
https://logging.apache.org/xml/ns/

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Deprecation of Log4j Supplier in 2.x...why? 

[Piotr P. Karwasz]

Hi Jeff,

On Fri, 15 Mar 2024 at 02:43,  wrote:
> Our builds are now ***full*** of deprecation warnings.  The IDE shows 
> deprecation highlighting everywhere. Also, CI builds i.e. with Sonar evaluate 
> use of deprecated API as Code Smells and Quality Gates fail.  When SQ quality 
> gates fail our downstream jobs don't trigger.

Since you are one of the few users that pays attention to compiler
warnings, may I ask you for an opinion?

We are considering annotating our code with JSpecify nullability
annotations[1], which has a big chance to become THE nullability
annotation standard (instead of the 15-th nullability annotation
standard). Which one of these options would you prefer:

* we add JSpecify as a `provided` dependency: Maven will not download
the dependency in projects using Log4j API, but users will get many
compiler warnings about missing annotations. These are just warnings:
missing annotations cause no problems at runtime. Of course a user can
get rid of the warnings by including JSpecify in its own dependencies,
* we add JSpecify as a `compile` dependency and force users to
download the (2 KiB) JAR file.

Piotr

[1] https://jspecify.dev/

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Deprecation of Log4j Supplier in 2.x...why? 

[Piotr P. Karwasz]

Hi Jeff,

On Fri, 15 Mar 2024 at 07:50,  wrote:
> Yes the Javadoc did a fine job of explaining the reason for the change and I 
> understood it, but there are so many side-effects from deprecating those 
> APIs.  My question was more of a "why do this in advance?" 

The deprecation was introduced as a requirement of semantic versioning:

"Before you completely remove the functionality in a new major
release there should be at least one minor release that contains the
deprecation so that users can smoothly transition to the new API."[1]

However in January this year (cf. [2]) we decided that we will not
release a Log4j API 3.x version in the foreseeable future. We will
only release a major version of our logging backend Log4j Core. I
guess this means we can remove the @Deprecated annotation. Personally
it bothers me too to introduce all those `@SuppressWarnings`
annotations.

> It took us unfortunately a long time to get to 2.x and I am pretty sure we 
> won't be jumping on the 3.0 version at release, so the idea of dealing with 
> those deprecations for another 1-2 years is sobering. 

While we chose the same Java baseline as Spring Boot 3.x (Java 17),
Log4j Core 3.x will be easier to deploy, since it will just require
the replacement of a runtime dependency.

Piotr

[1] https://semver.org/#how-should-i-handle-deprecating-functionality
[2] https://lists.apache.org/thread/p2lgr3xtt9hq77j7r67r8x1tc1z7kbol

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: log4j initialization does not seem to happen when Tomcat service is started

[Piotr P. Karwasz]

Hi Piers,

On Thu, 14 Mar 2024 at 14:08, Piers Uso Walter  wrote:
> However, what I was trying to achieve by using a servlet context listener was 
> to be able to set the location of the log4j configuration file at run time.
> I’m trying to make the app compatible with different app servers where 
> configuration files are typically placed in different locations.
> So I’m figuring out at run time which app server the app is running in, and 
> based on that I know where to expect the log4j configuration file.

Can provide more details as to where the path to the configuration
file is actually stored? If you change the `log4j2.configurationFile`
property, other web apps on the same server will be affected, which
might be an unpleasant surprise to users. There are less invasive ways
to do that.

I also wonder if maintaining container specific code is worth the
effort. Many application servers have a detailed guide to configuring
logging (e.g. WildFly[1]). Users might be unwilling to learn yet
another way to configure logging.

Sure, Tomcat is an exception, that is why I maintain a small set of
Log4j Core plugins and Tomcat extensions[2] to help users
administering logging at a global level.

Piotr

[1] https://docs.wildfly.org/31/Admin_Guide.html#Logging
[2] https://github.com/copernik-eu/log4j-tomcat

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Deprecation of Log4j Supplier in 2.x...why? 

[Piotr P. Karwasz]

Hi Jeff,

On Fri, 15 Mar 2024 at 02:43,  wrote:
> One of the great new features of Log4j2 is the lambda lazy logging.
>
> Since we migrated to Log4j2 we have liberally been trying to take advantage 
> of this where we can.
>
> In the last few releases though, in preparation for Log4j 3.x the Log4j 
> Supplier has been deprecated without replacement.

Sorry, if we were not specific enough in the Javadoc[1]. We would like
to replace `org.apache.logging.log4j.util.Supplier` with
`java.util.function.Supplier`, which is a source compatible change:
the compiler will just convert lambdas to another interface.

However this is more of a very long-term plan, which would probably
require an entirely new package name and `Logger` interface.
Effectively we should remove the `@Deprecated` annotation from our
code and just keep the Javadoc description.

Piotr

[1] 
https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/Supplier.html

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: log4j initialization does not seem to happen when Tomcat service is started

[Piotr P. Karwasz]

Hi Piers,

On Wed, 13 Mar 2024 at 22:29, Piers Uso Walter  wrote:
> 2024-03-13T19:49:02.609143Z Catalina-utility-1 INFO 
> Log4jServletContextListener triggered a Log4j context initialization.
>
> Case 2:
> However, if I stop and restart the Tomcat service (with the war file having 
> been previously deployed), the app no longer logs anything and I don’t see a 
> catalina log line about Log4j context initialization:

The message in the first line is not logged through Log4j Core, but
the status logger (an internal logging system of the Log4 API). You
can set the level of the status logger using the
`log4j2.StatusLogger.level` property. By default it only shows `ERROR`
messages, but it changes level based on the `status` property

> I configured a servlet context listener in order to be able to set the system 
> property log4j.configurationFile upon application start.
> This allows me to place the log4j configuration file outside of the war file.

A servlet context listener is not the right tool for this, since it is
executed **after** Log4j's `ServletContainerInitializer`.
You should rather specify the property as a servlet context init
parameter. See the current documentation:

https://logging.apache.org/log4j/2.x/manual/webapp.html#configuration

or a preview of the documentation of the next major version:

https://logging.staged.apache.org/log4j/jakarta/latest/#log4j-jakarta-web-configuration

> This is my web.xml:
> 
> http://www.w3.org/2001/XMLSchema-instance; 
> xmlns="http://xmlns.jcp.org/xml/ns/javaee; 
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; id="WebApp_ID" 
> version="3.1">
>
> 
> 
> 
> de.ilink.cloud.ucc.gw.LdapGwServletContextListener
> 
>
> 

You should add:


log4jConfiguration
path_to_your_config_file_or_resource


Also if your context listener uses logging, you might want to register
a `Log4jServletContextListener` manually, so it shuts down **after**
your listener:



org.apache.logging.log4j.web.Log4jServletContextListener




de.ilink.cloud.ucc.gw.LdapGwServletContextListener


Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

GraalVM support in Log4j Core

[Piotr P. Karwasz]

Hi all,

For Q3-Q4 we plan to introduce native GraalVM support in Log4j Core.

This can be implemented in at least two ways:

* you can have slim binaries with only the Log4j Core components
necessary for your configuration,
* you can have larger binaries, but be able to digest any valid Log4j
Core configuration file.

Unfortunately we don't know which approach will be the best for most
users. If you are using Log4j Core in a GraalVM application, please
provide us some feedback in this Github discussion:

https://github.com/apache/logging-log4j2/discussions/2364

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Apache Log4j 2.23.0 released

[Piotr P. Karwasz]

The Apache Log4j team is pleased to announce the 2.23.0
release. Apache Log4j is a versatile, industrial-strength
Java logging framework composed of an API, its implementation,
and components to assist the deployment for various use cases.
For further information (support, download, etc.) see the project
website[1].

[1] https://logging.apache.org/log4j/2.x/

== Release Notes

This release adds support for LMAX Disruptor 4.x and several
performance and bug fixes.

In order to maintain compatibility with JRE 8, support for LMAX
Disruptor 3.x is maintained.

=== Added

* Added support for LMAX Disruptor 4.x (#1821)

=== Changed

* Simplify BND configuration after upgrade from version `6.4.1` to `7.0.0`

=== Deprecated

* Deprecate the configuration attribute `verbose` (i.e.,
` node to appear in any position in the
configuration element.
* Fix forgotten `threadName` field in `RingBufferLogEvent#clear()` (#2234)
* Fix `StringBuilder` cache corruption on recursive access
* Fixed use of `SecurityManager` in `LoaderUtil` where
`AccessController::doPrivilege

d` should only be invoked when a
`SecurityManager` is installed. Some runtimes do not seem to have this
method available. (#2129)
* Fix `log4j-spring-cloud-config-client` dependencies to include only
those required. (#2157)
* Fix typo in Kubernetes `clientKeyData` configuration property.

=== Updated

* Update `com.fasterxml.jackson:jackson-bom` to version `2.16.1` (#2126)
* Update `commons-codec:commons-codec` to version `1.16.1` (#2277)
* Update `io.netty:netty-bom` to version `4.1.107.Final` (#2284)
* Update `org.apache.logging:logging-parent` to version `10.6.0` (#2197)
* Update `org.eclipse.jetty:jetty-bom` to version `9.4.54.v20240208` (#2287)
* Update `org.jctools:jctools-core` to version `4.0.3` (#2270)
* Update `org.springframework:spring-framework-bom` to version `5.3.32` 
(#2293)

* Update `org.zeromq:jeromq` to version `0.6.0` (#2271)

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Apache Log4j 3.0.0-beta2 released

[Piotr P. Karwasz]

The Apache Log4j team is pleased to announce the 3.0.0-beta2
release. Apache Log4j is a versatile, industrial-strength
Java logging framework composed of an API, its implementation,
and components to assist the deployment for various use cases.
For further information (support, download, etc.) see the project
website[1].

[1] https://logging.apache.org/log4j/3.x/

== Release Notes

This release provides a continuation of the modularisation process of
Log4j Core.

The following features were moved to separate artifacts:

* The async logger feature was moved to `log4j-async-logger` and it
was upgraded to use LMAX Disruptor 4.x.
The async appender is still available by default in `log4j-core`.
* The YAML configuration is available now in `log4j-config-yaml`.
* The Java properties configuration was removed and replaced with a
similar format based on `jackson-dataformat-properties` in a new

`log4j-config-properties` artifact.


Other features were removed:

* Jetty 9.x users are encouraged to migrate to Jetty 10.x or later and
replace `log4j-appserver` with `log4j-slf4j2-impl`.
* Tomcat JULI support will be available from a third-party (cf.
https://github.com/copernik-eu/log4j-plugins 
).

* Apache Commons Logging users are encouraged to upgrade
`commons-logging` to version 1.3.0 or later and remove `log4j-jcl`.
* Support for the XML layout was dropped.
* Support for JMX was dropped and will be replaced with a more recent
technology.

=== Added

* Add and update DSLs for setting up dependency injection for test and
non-test code. (#2147)
* Add a `ConfigurationExtension` mechanism to allow third-party JARs
to extend the `` element.
* Add a new properties configuration factory based on
`jackson-dataformat-properties`.

=== Changed

* Change the order of evaluation of `FormattedMessage` formatters.
Messages are evaluated using `java.util.Format` only if they don't
comply to the `java.text.MessageFormat` or `ParameterizedMessage`
format. (#1223)
* Split off async logger support into a new `log4j-async-logger` module.
* Split off YAML configuration into a new `log4j-config-yaml` module.

=== Fixed

* Rewrote message parameter formatter with improved escape handling (#1626)
* The MongoDb4 appender now supports long values to configure
`collectionSize` (#1747)
* Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098)
* Fix regression in `JdkMapAdapterStringMap` performance. (#2238)
* Prevents ClassCastException when trying to assign a
SimpleLoggerContext to a core LoggerContext (LOG4J2-1921)
* Possible NullPointerException in MongoDb4DocumentObject,
MongoDbDocumentObject, DefaultNoSqlObject. (LOG4J2-3392)
* Fix NPE in `CloseableThreadContext`. (#1426)
* Fix NPE in `RollingFileManager`. (#1645)
* Fix `log4j-spring-cloud-config-client` dependencies to include only
those required. (2157)
* Workaround a Coursier/Ivy dependency resolution bug affecting
`log4j-slf4j-impl` and `log4j-mongodb3`. (#2065)

=== Removed

* Removed legacy `2.x` properties configuration factory.
* Remove `DefaultLogEventFactory`
* Remove `log4j-appserver` module (#2257)
* Remove `org.apache.logging.log4j.core.parser` and related packages. 
(#2154)

* Remove `log4j-jcl` module (#2257)
* Removed JMX support.
* Remove `log4j-layout-jackson` module (#2198)
* Remove `log4j-layout-jackson-xml` module (#2198)
* Remove `log4j2.enable.threadlocals` property (#2105)

=== Updated

* Update `com.fasterxml.jackson:jackson-bom` to version `2.16.1` (#2127)
* Update `commons-codec:commons-codec` to version `1.16.1` (#2276)
* Update `io.netty:netty-bom` to version `4.1.107.Final` (#2283)
* Update `org.apache.logging:logging-parent` to version `10.6.0` (#2193)
* Update `org.apache.tomcat:tomcat-juli` to version `10.1.18` (#2176)
* Update `org.eclipse.jetty:jetty-bom` to version `9.4.54.v20240208` (#2285)
* Update `org.jctools:jctools-core` to version `4.0.3` (#2267)
* Update `org.slf4j:slf4j-api` to version `2.0.10` (#2136)
* Update `org.springframework.boot:spring-boot-autoconfigure` to
version `3.2.2` (#)
* Update `org.springframework.cloud:spring-cloud-context` to version
`4.1.1` (#2236)
* Update `org.springframework:spring-framework-bom` to version `6.1.4` 
(#2294)


-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: ImmediateFlush setting is ignored in properties-based configuration

[Piotr P. Karwasz]

Hi Christopher,

On Fri, 2 Feb 2024 at 23:54, Christopher Schultz
 wrote:
> I'm using log4j 2.17.1.

There have been tons of bug fixes in `log4j-1.2-api`, especially in
version 2.17.2:

https://logging.apache.org/log4j/2.x/release-notes.html#release-notes-2-17-2

Can you check with the latest version?

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Async logger not logging after upgrading tomcat, jdk and log4j

[Piotr P. Karwasz]

Joan,

On Fri, 26 Jan 2024 at 13:33,  wrote:
> Issue fixed. The problem was in the disruptor library, which we also migrated 
> from 3.4.4 to 4.0.0. Downgrading again to 3.4.4. fixed the problem.

Thank you for sharing your solution with us. Since nobody was able to
diagnose this problem from your status logs, I opened issue #2250[1]
to add the correct log statements during the initialization of LMAX
Disruptor.

Note also, that the upcoming version 2.23.0 will support both LMAX
Disruptor 3.x and 4.x (cf. issue #1829[2]), so you'll be able to
upgrade to 4.x.

As far as version 3.x of Log4j is concerned, our upcoming 3.0.0-beta2
will feature a separate `log4j-async-logger` artifact with a
non-optional dependency on `com.lmax.disruptor:disruptor`[3]. We hope
to relieve users from the burden of upgrading the Disruptor library
themselves and rely on the transitive dependency in
`log4j-async-logger`.

Piotr

[1] https://github.com/apache/logging-log4j2/issues/2250
[2] https://github.com/apache/logging-log4j2/issues/1829
[3] https://github.com/apache/logging-log4j2/pull/2241

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Async logger not logging after upgrading tomcat, jdk and log4j

[Piotr P. Karwasz]

Hi Joan,

On Thu, 25 Jan 2024 at 12:06,  wrote:
> My application has been using async logging for years by setting this env 
> variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector
>
> Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the 
> above variable set, nothing is logged. If I remove it then it starts to log 
> again, but without async.
>
> Is there any change I'm missing regarding this async logging when moving to 
> these new versions of tomcat, java and log4j?

Can you test with
`-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector`
since `Log4jContextSelector` is deprecated since 2.10?

Although it should have no influence on the context selector, if you
were using `log4j-web`, did you switch to `log4j-jakarta-web`?

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Support of log4j2

[Piotr P. Karwasz]

Hi Mickael,


On Wed, 10 Jan 2024 at 15:53, Mickael Maison  wrote:
> I see that log4j3 is about to release, so I'm wondering what are the
> plans regarding future development and maintenance of log4j2? Do you
> expect to keep releasing new 2.X versions? How long do you expect to
> still maintain 2.X releases?

Something the other comments didn't specify is that `log4j-api` 3.x
will not break binary compatibility with `2.x` from a user's
perspective.
There will be some changes also there, but they should only concern
Log4j APi implementors and Log4j Core plugin providers.

> To provide a bit of context, the Apache Kafka project is considering
> switching to log4j2, but we're concerned that with log4j3, log4j2 will
> soon enter end of life.

That is great news. Are you planning to switch APIs (from SLF4J to
Log4j API) or implementations (from Reload4j to Log4j Core)?

The first operation should be easy, since we recently contributed an
SLF4J to Log4j API OpenRewrite recipe:

https://github.com/openrewrite/rewrite-logging-frameworks/releases/tag/v2.4.0

The second operation should be trivial, since you just need to convert
the configuration file in your binary distribution. For simple case
you can also use `Log4j1ConfigurationConverter`:

https://github.com/apache/logging-log4j2/blob/2.x/log4j-1.2-api/src/main/java/org/apache/log4j/config/Log4j1ConfigurationConverter.java

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Apache Log4j Kotlin API 1.4.0 released

[Piotr P. Karwasz]

The Apache Log4j Kotlin API team is pleased to announce the 1.4.0
release. This project contains a Kotlin-friendly interface to log
against the Log4j API. For further information (support, download,
etc.) see the project website[1].

[1] https://logging.apache.org/log4j/kotlin/

=== Release Notes

This minor release fixes incorrect coroutine context map and stack.


 Added

* Started generating CycloneDX SBOM with the recent update of
`logging-parent` to version `10.2.0`

 Changed

* Coroutine context is not cleared properly, only appended to (#54)
* Update `org.apache.logging:logging-parent` to version `10.2.0`
* Update `org.apache.logging.log4j:log4j-bom` to version `2.22.0` (#52)
* Update `org.apache.logging:logging-parent` to version `10.4.0` (#53)
* Update `org.codehaus.mojo:build-helper-maven-plugin` to version `3.5.0` (#51)
* Update `org.codehaus.mojo:exec-maven-plugin` to version `3.1.1` (#50)
* Update `org.junit:junit-bom` to version `5.10.1` (#49)

Apache Log4j Kotlin API team

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Apache Log4j 2.22.1 released

[Piotr P. Karwasz]

The Apache Log4j team is pleased to announce the 2.22.1
release. Apache Log4j is a versatile, industrial-strength
Java logging framework composed of an API, its implementation,
and components to assist the deployment for various use cases.
For further information (support, download, etc.) see the project
website[1].

[1] https://logging.apache.org/log4j/

== Release Notes

This release contains only dependency upgrades and bug fixes, which do
not change the behavior of the artifacts.

While maintaining compatibility with Java 8, the artifacts in this
release where generated using JDK 17, unlike version `2.22.0` that
used JDK 11.

=== Fixed

* Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098)
* Fix NPE in `CloseableThreadContext`. (#1426)
* Use the module name of Conversant Media Disruptor from version
`1.2.16+` of the library.
* Fix NPE in `RollingFileManager`. (#1645)
* Fix `log4j-to-slf4j` JPMS and OSGi descriptors. (#1983)
* Workaround a Coursier/Ivy dependency resolution bug affecting
`log4j-slf4j-impl` and `log4j-mongodb3`. (#2065)

=== Updated

* Bumped the minimum Java version required for the build to Java 17.
Runtime requirements remain unchanged. (#2021)
* Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2030)
* Update `com.google.guava:guava` to version `33.0.0-jre` (#2110)
* Update `commons-codec:commons-codec` to version `1.16.0` (#2042)
* Update `commons-io:commons-io` to version `2.15.1` (#2034)
* Update `commons-logging:commons-logging` to version `1.3.0` (#2050)
* Update `io.netty:netty-bom` to version `4.1.104.Final` (#2095)
* Update `org.apache.commons:commons-compress` to version `1.25.0` (#2045)
* Update `org.apache.commons:commons-dbcp2` to version `2.11.0` (#2048)
* Update `org.apache.commons:commons-lang3` to version `3.14.0` (#2047)
* Update `org.apache.commons:commons-pool2` to version `2.12.0` (#2057)
* Update `org.apache.kafka:kafka-clients` to version `3.6.1` (#2068)
* Update `org.apache.logging:logging-parent` to version `10.5.0` (#2119)
* Update `org.jctools:jctools-core` to version `4.0.2` (#1984)
* Update `org.springframework.boot:spring-boot` to version `2.7.18` (#1998)
* Update `org.springframework.cloud:spring-cloud-dependencies` to
version `2021.0.9` (#2109)

Apache Log4j Team

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: [ANNOUNCE] Log4j module deprecation

[Piotr P. Karwasz]

On Mon, 6 Nov 2023 at 23:14, Piotr P. Karwasz  wrote:
>
> In order to concentrate our limited resources on the remaining modules,
> the PMC decided to deprecate the following modules/features in 2.x and
> to remove them in 3.x:
>  * `log4j-cassandra`,
>  * CouchDB appender,
>  * GELF appender,
>  * Kafka appender,
>  * jeroMQ appender,
>  * `log4j-jpa`,
>  * `log4j-mongodb3`,
>  * `log4j-spring-boot`,
>  * Java EE SMTP appender,
>  * `log4j-taglib`.

Correction: this list should also include JsonLayout (replaced by
JsonTemplateLayout) and YamlLayout.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Log4j module deprecation

[Piotr P. Karwasz]

In order to concentrate our limited resources on the remaining modules,
the PMC decided to deprecate the following modules/features in 2.x and
to remove them in 3.x:
 * `log4j-cassandra`,
 * CouchDB appender,
 * GELF appender,
 * Kafka appender,
 * jeroMQ appender,
 * `log4j-jpa`,
 * `log4j-mongodb3`,
 * `log4j-spring-boot`,
 * Java EE SMTP appender,
 * `log4j-taglib`.

Each of these modules either has a valid (and maintained) third-party
alternative or its usage has been deemed irrelevant.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j module deprecation

[Piotr P. Karwasz]

Hi all,

On Thu, 28 Sept 2023 at 09:35, Piotr P. Karwasz  wrote:
> We know that statistics are not everything and that is why we would
> like to hear your opinion on these modules. The discussion will be
> open for a month, after which the PMC will announce a definitive list
> of deprecations.

It has been more than a month since I sent the announcement. I'll
prepare an e-mail and submit it to `dev` for a vote.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Apache Log4j 2.21.1 released

[Piotr P. Karwasz]

Apache Log4j team is pleased to announce the 2.21.1
release. Apache Log4j is a versatile, industrial-strength
Java logging framework composed of an API, its implementation,
and components to assist the deployment for various use cases.
For further information (support, download, etc.) see the project
website[1].

[1] https://logging.apache.org/log4j

== Release Notes

This patch release contains only the fix of a `log4j-jcl` bug that
prevents it from connecting with `commons-logging`.

The Log4j 2.21.1 API, as well as the other artifacts, maintains binary
compatibility with the previous release.

Apache Log4j 2.21.1 requires Java 8 to run.
The build requires JDK 11 and generates reproducible binaries.

For complete information on Apache Log4j 2, including instructions on
how to submit bug reports, patches, get support, or suggestions for
improvement, see the Apache Log4j 2.x website[2].

[2] http://logging.apache.org/log4j/2.x/

=== Fixed

* Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865)

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Log4j module deprecation

[Piotr P. Karwasz]

Hi all,

We always strive to only release industrial-strength components.

Following an internal discussion and looking at statistics from
several sources, the PMC plans to deprecate in the 2.x version several
components for removal in 3.x.

We know that statistics are not everything and that is why we would
like to hear your opinion on these modules. The discussion will be
open for a month, after which the PMC will announce a definitive list
of deprecations.

## `log4j-cassandra`:
We support Cassandra 3.x. This release will reach end-of-life when
4.2.x is released[1]. Since the stats show marginal usage of the
module, there should be no `log4j-cassandra4`.

## CouchDB appender:
   It is even less used than Cassandra according to the stats.

## `log4j-docker`
Seldom used and standard practice is generally to log to the
console and let the Docker environment add the data.

## GELF appender:
It is mostly superseded by `JsonTemplateLayout`.

## Kafka appender:
It contains several critical bug reports neither the PMC, nor the
community is willing to deal with.

## `log4j-kubernetes`:
Seldom used and standard practice is generally to log to the
console and let the Docker environment add the data.

## JeroMQ appender:
Since version 2.6 it had only one PR/bug report and it was from
PAX Logging maintainer. There is an alternative from a ZeroMQ
maintainer[2], Fabrice Bacchella, that provides important features
like encryption or choice of socket type.

## JNDI-related features:
JNDI is an old technology from the times of ponies and unicorns,
when nobody cared about security. The Error Prone team decided to mark
JNDI usage as error by default[3].

## `log4j-jpa`:
Has marginal downloads and requires a migration to Jakarta EE. I
think that `log4j-jdbc` (which is also seldom used) provides a good
alternative for SQL databases,

## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
used and `YamlLayout` as far as we know is not be used at all.

## `log4j-mongodb3`:
Support for MongoDB 3.x ended two years ago.

## `log4j-spring-boot`:
Its features are included in Spring Boot 3.x.

## SMTP appender:
Its usage is at the bottom of the stats.

## `log4j-taglib`
Also needs a Jakarta version, but it is based on a legacy
technology that is currently seldom used.

Waiting to hear your opinions,
Piotr

[1] 
https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
[2] https://github.com/fbacchella/loghublog4j2
[3] https://errorprone.info/bugpattern/BanJNDI

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Multiple applications using GetLogger with same name

[Piotr P. Karwasz]

Hi Ralph,

On Tue, 1 Aug 2023 at 20:58, Ralph Goers  wrote:
> 2. Partition your application so that the main application and each batch job 
> use their own ClassLoader. The ClassLoaderContextSelector (the default) will 
> then create a LoggerContext for each ClassLoader and each can have its own 
> configuration.

This is not so easy with the current ClassLoaderContextSelector: if
the parent classloader already has a logger context and the context
selector was called with `configLocation=null` (which is almost always
the case), the ClassLoaderContextSelector returns the logger context
of the parent classloader.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Multiple applications using GetLogger with same name

[Piotr P. Karwasz]

Hi Danish,

On Tue, 1 Aug 2023 at 20:10, Danish Arif  wrote:
> My use case is that my application uses the above mentioned method to get
> logger and log. Appender and Logger have been set in log4j2.xml file. We
> stop the Logger by getting all core appenders , removing them , then
> stopping them and then using the LogManager.shutdown() method.

There is no need for that, because:
1. LogManager.shutdown() stops all appenders,
2. Usually the `log4j2.shutdownHookEnabled` property is set to true,
so LogManager.shutdown() is called by a shutdown hook.

> The issue or anomaly arises when an update batch script starts the new
> instance of the same application and the old instance takes some time to
> exit, resulting in new instance getting the same logger using
> LogManager.getLogger("AppName"); and writing in the same log file.
>
> Once the 1st/old instance exists after a few seconds, it closes all the
> logging and nothing on the file gets written even when the 2nd/new instance
> is still up and running.

If these instances are in different JVM's, this is strange: can you
add the configuration of your file appender?
If you are using a `RollingFileAppender`, it can rotate your file and
delete the old ones.

If these instances are in the same JVM, you might be up to something:
apparently `stop()` is not idempotent and if you call it enough times,
you can effectively stop appenders in other logger contexts.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Facing issue in while doing migration log4j 1.x to 2.x

[Piotr P. Karwasz]

Hi Nishu,
Sorry for the delay,

On Wed, 24 May 2023 at 06:47, Nishu Gupta 
wrote:> I did the set the `log4j1.compatibility` to `true` in the
custom properties.
>
> Do I need to use the log4j.xml while using the bridge jar? or I need to 
> convert to log4j2.xml as well?

My rule of thumb on this is for developers to use a `log4j2.xml`
configuration and leave to end users the possibility of using a
`log4j.xml`.
Converting from a restrictive Log4j 1.x configuration file to the more
powerful Log4j 2.x format is a one-time job. Unless you need custom
legacy components I don't see a reason not to do it.

On Wed, 31 May 2023 at 13:27, Nishu Gupta  wrote:
> Here is the log4j and lo4j2 xml.
>
> I need a help for how jms call trigger?
>
>   class="com.aba.package.MyProject"
>  provideUrl="abcde://abc.test.com:3226"
>  initialContextFactory="com.abc.naming.abcdeInitialContextFactory"
>  queueConnectionFactoryBindingName="abc.def.qwe.ms"
>  queueBinding="anc.def.create"
>  messageOnly="true"
>  username="abc"
>  password="abc">
> 
>
>threshold="INFO"
>   provideUrl="abcde://abc.test.com:3226"
>   initialContextFactory="com.abc.naming.abcdeInitialContextFactory"
>   queueConnectionFactoryBindingName="abc.def.qwe.ms"
>   queueBinding="anc.def.create"
>   messageOnly="true"
>   username="xyz"
>   password="xyz"
>   queueDeliveryMode="2">
> 

I am not an expert on JMS, but your configuration has many errors:

 * there is **no** "JMSQueue" plugin,
 * you use a lot of properties that do not exist (cf.
https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender
). E.g. `initialContextFactory` should be `factoryName`, `provideUrl`
should be `providerURL` and so on.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: how to use log4j-to-jul with log4j-web

[Piotr P. Karwasz]

Hi Jason,

On Sat, 3 Jun 2023 at 00:13, Jason Guild  wrote:
> The application currently uses log4j-web to get the all the essential
> setup for initializing log4j 2 under an application container. The
> log4j-web library appears to have a hard dependency on log4j-core.

The `log4j-web` module is only useful to initialize the `log4j-core`
implementation of the Log4j 2.x API. If you don't use `log4j-core` you
don't need it.



On Sat, 3 Jun 2023 at 02:23, Ralph Goers  wrote:
>
> When using log4j-to-jul you cannot use ANY other log4j modules except for 
> log4j-api. You must configure Tomcat’s logging to handle all the logging for 
> your application.

That is a little bit oversimplified. There are a lot of Log4j modules:

 * some like `log4j-layout-template-json` or `log4j-web` contain
components for `log4j-core`. These can not be used with
`log4j-to-jul`.
 * other modules contain adapters from framework X to Log4j 2.x API
(e.g. `log4j-slf4j-impl`) or depend only on the Log4j 2.x API (e.g.
`log4j-iostreams`). These can be used with `log4j-to-jul`.

At work we use `log4j-api` + `log4j-to-jul` for all application
logging together with:

 * `log4j-slf4j-impl` (the dependency on `log4j-core` is just for the
comfort of most users and can be safely excluded), `log4j-jcl` and
`log4j-iostreams` to forward everything other logging framework to
Log4j 2.x API,
 * a `WEB-INF/classes/logging.properties` file that provides
per-application configuration (using the standard
ClassLoaderLogManager JUL implementation shipped with Tomcat). The
`${classloader.webappName}` variable comes very handy here.

Logging is not very important for our clients and this limits our
responsibility in case of problems with `log4j-core`.

Obviously this is hardly a useful setup during development and tests,
so our test machines use my Log4j extensions[1] to delegate all Log4j
2.x API calls to a `log4j-core` installation in Tomcat's system
classloader.

Piotr

[1] https://github.com/copernik-eu/log4j-plugins

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Facing issue in while doing migration log4j 1.x to 2.x

[Piotr P. Karwasz]

Hi Nishu,

On Tue, 16 May 2023 at 07:25, Nishu Gupta  wrote:
> Currently I am using log4j 1.x version. I am trying to migrate from 1.x to =
> 2.x using bridge jar.
>
> we are using below category in log4j1.xml
>  eAppender">
>
> (...)
>
> I am trying to convert into logj2.xml and we have custom class JMSQueueAppe=
> nder which extends AppenderSkeleton for logging the event.

Native Log4j 1.x appenders do work with Log4j 2.x if you:
 * use the `log4j-1.2-api` bridge,
 * use a Log4j 1.x configuration,
 * either set the system property `log4j.configuration` to the
location of the above mentioned configuration or set
`log4j1.compatibility` to `true`.

These can constitute a fast **transitional** solution. You won't have
access to all the configuration options of `log4j2.xml`, but you will
not need to rewrite your appender.

To fully migrate to Log4j 2.x you need:
 * either switch from your custom JMS appender to the one shipped with
`log4j-core`: 
https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender
 * or rewrite your appender as a native Log4j 2.x Appender.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

[ANNOUNCE] Apache Log4j Transformation Tools 0.1.0 released

[Piotr P. Karwasz]

The Apache Log4j 2 team is pleased to announce the Apache Log4j
Transformation Tools 0.1.0 release!

Apache Log4j Transformation Tools is a subproject of Apache Log4j that
provides binary manipulation tools for Log4j-enabled software.

In this first release you'll find:

• A Maven plugin to precompute the location of your logging
statements. This allows you to include source location in your layout
configuration with virtually no performance penalty.
• The well known `maven-shaded-log4j-transformer` by Eduard
Gizatullin (https://github.com/edwgiz/maven-shaded-log4j-transformer),
that has been donated to the Apache Software Foundation by its author.

You can find the project documentation at:
https://logging.apache.org/log4j/2.x/log4j-transform

The binary artifacts are available in the Apache Maven repository:

https://repository.apache.org/content/repositories/releases/

and also on Maven Central repository (https://repo1.maven.org/maven2/)
and its mirrors.

The source distribution is available at:
https://dist.apache.org/repos/dist/release/logging/log4j-transform/0.1.0/

Bug reports, patches or suggestions for improvement can be submitted
through Github Issues:
https://github.com/apache/logging-log4j-transform/issues

This release is dedicated to my wife Agnieszka for her birthday.

Piotr Karwasz

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Need help in configuring localHostname in log4j2 syslog appender

[Piotr P. Karwasz]

Hi Ganesh,

On Tue, 2 May 2023 at 04:12, Ganesh S  wrote:
> I'm trying to implement remote logging for my application which is running
> in a docker container.
> The remote server provider is Papertrail.
> I want to specify a custom local host name, currently it is taking
> container id, which I don't want.

As Volkan explained, Log4j2 uses the hostname of your OS as syslog hostname.

I think that your problem is that the hostname of your Docker
container is not what you would expect. You can change it with
`--hostname` parameter to `docker run`:

https://docs.docker.com/config/containers/container-networking/

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Having trouble changing a logger's level (threshold) at runtime

[Piotr P. Karwasz]

Hi Chris,

On Tue, 28 Feb 2023 at 20:04, Christopher Schultz
 wrote:
> What is the recommended technique for changing a single logger's
> threshold in log4j2? I realize that the best thing to do would be to
> "just configure it correctly the first time" but in reality, you
> sometimes just have to enable TRACE logging in production to figure out
> what the hell is happening.

The recommended approach is to dynamically update your configuration.
Log4j2 Core does not lose events during a reconfiguration event.
By setting a `monitorInterval` attribute on the ``
component[1], Log4j2 will monitor your configuration source (anything
with a Java URL handler) and reconfigure the logging system when it
changes.

Another approach is through global filters (filters directly attached
to the Configuration object), that are evaluated *before* a logger's
level. If they return ACCEPT or DENY, the message is unconditionally
accepted or denied.
Recently Ralph added the (undocumented?)
MutableThreadContextMapFilter[2], which works like its documented
counterpart[3], but regularly reads its configuration from an URL
(configLocation attribute).
This can be used e.g. to increase the logging level for a specific
user dynamically.

If you really require programmatic configuration,
Configurator.setLevel[4] is the most stable way. As you noticed,
Configuration#getLoggerConfig gives you the *effective* configuration
of the logger, which could be the configuration of its parent or even
the root logger.

Piotr

[1] 
https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration
[2] 
https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/filter/MutableThreadContextMapFilter.Builder.html
[3] 
https://logging.apache.org/log4j/2.x/manual/filters.html#ThreadContextMapFilter
[4] 
https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/config/Configurator.html

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: PatternLayout caching system property lookup values

[Piotr P. Karwasz]

Hi Stig,

On Fri, 18 Nov 2022 at 11:03, Stig Døssing
 wrote:
> Is there a way to disable this “permanent substitution” and get log4j to do 
> the system property lookup for every log event, even if there is a default 
> value? If not, should there be? System properties can be changed from inside 
> the application, so it seems strange to assume that if a system property has 
> a value during logging init, it will keep that same value permanently.

The `${...}` placeholders are replaced at configure time. If no value
is available, they are left as is (this is IMHO a bug).

If you want to evaluate the lookup at each logging event, just escape
the dollar sign: `$${sys:testProperty}`. At configuration time one
dollar sign will be stripped, so that the lookup will be performed at
every logging event.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: ETA for 2.19.1?

[Piotr P. Karwasz]

Hi Jeff,

On Fri, 11 Nov 2022 at 15:58,  wrote:
> I just discovered the Junit hooks and have been using them out in my test 
> code - nice way of testing logging with a clean context.

Can you provide an example on how you use the JUnit extensions in your
application test code?

The JUnit extensions used in Log4j2 are mostly useless, when testing
applications: applications usually use static loggers (Log4j2
internally only uses StatusLogger), which will be bound to the logger
context used at the moment of their static initialization. Subsequent
LoggerContext reloads (as those caused by @LoggerContextSource) are
useless.

The only component that can be used to test applications is the ListAppender.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Issue after moving to log4j 2.19

[Piotr P. Karwasz]

Hi Joan,

On Sun, 16 Oct 2022 at 00:45, Joan ventusproxy
 wrote:
> The " log4j.configurationFile " variable is set in this way:
> System.setProperty("log4j.configurationFile", 
> "/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");

For some unknown reason this is executed too late (after Log4j2
configuration). In the second file you posted you can see that Log4j2
is initialized twice: the first time the logger context associated
with your web app's classloader  picks up the default configuration,
because no `log4j2.configurationFile` setting is visible. Then
`log4j-web` configures what seems to be a second logger context with
your configuration (but `log4j-web` uses the `ServletContext` init
params to retrieve the configuration).

To find which component calls Log4j2 before `log4j-web` you can use
`-Dlog4j2.loggerContextStacktraceOnStart=true`. The web fragment
`log4j` contained in `log4j-web` requests to be executed before all
others, but you can change it with `` in your
`web.xml`.

> And tomcat starts with:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

This setting basically breaks `log4j-web` ("WARN StatusLogger
Potential problem: Selector is not an instance of
NamedContextSelector."). Look into your web application descriptor and
remove the `isLog4jContextSelectorNamed` parameter. You can also use
the `BasicAsyncLoggerContextSelector` which always selects a thread
bound logger context (`log4j-web` manages the thread binding).

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: JPMS Native Log4j?

[Piotr P. Karwasz]

Hi Clayton,

On Fri, 14 Oct 2022 at 17:32, Clayton Wohl  wrote:
>
> I've heard rumors that the log4j devs are working on a Java 11+ JPMS native
> version of log4j. This would help end users use jlink to package/distribute
> their applications. Is this still happening? Is there a ballpark time
> frame for when we will see pre-release builds?

The upcoming 3.x series will fully support JPMS. See the `master`
branch: https://github.com/apache/logging-log4j2/tree/master

While it is now our main development effort and snapshots are
published regularly (on
https://repository.apache.org/content/groups/snapshots) after each
commit, it is not very well tested by the community. JPMS-savy
contributors are always welcome.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Issue after moving to log4j 2.19

[Piotr P. Karwasz]

Hi Joan,

> After making a lot of tests trying to get this working again, we had to 
> change the line below:
>
> this.systemLog = LogManager.getLogger("LOGGER_SYSTEM");
>
>  �
>
> By this:
>
> this.systemLog = LogManager.getContext().getLogger("LOGGER_SYSTEM");

This looks like a `LoggerContextSelector` problem:
https://logging.apache.org/log4j/2.x/manual/extending.html#ContextSelector

`LogManager.getContext()` should not be used, because it gives you the
wrong logger context most of the time.
 The automatic configuration uses `LogManager.getContext(false)` to
retrieve the right logger context.

Can you run your application with `-Dlog4j2.debug=true` and share the output?

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Difference between the Date lookup $${date:yyyy-MM} and the Format Specifier %d{yyyy-MM}?

[Piotr P. Karwasz]

Hi Rick,
I gave a longer answer about this a couple of months ago on StackOverflow:

https://stackoverflow.com/q/71862896/11748454

Basically the delayed lookup `$${date:...}` uses the current time,
when the rollover occurs, while the pattern `%d{...}` uses the date of
the previous rollover.

A `RollingFileAppender` also uses the first (and hopefully only)
pattern it finds to determine the rollover frequency.

Piotr

On Fri, 2 Sept 2022 at 06:21, Rick  wrote:
>
> Hi,
>
> I am new to Log4j2, and I am a little bit confused with the Date lookup
> $${date:-MM} and the Format Specifier %d{-MM}.
> Please see the following configuration:
>
>  filePattern="logs/*$${date:-MM}*/app-*%d{MM-dd-}*-%i.log.gz">
>
>
> --
>
> Sincerely,
>
> *Rick Qin*
> Email: rickq...@gmail.com

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: "ERROR StatusLogger Reconfiguration failed" when running log4j-1.2-api from uber-jar

[Piotr P. Karwasz]

Hi Alain,

On Thu, 7 Jul 2022 at 11:35, Alain Désilets  wrote:
> If you look at my pom, you can see that there is a filter in the
> configuration of the shade plugin that remove the Log4j2Plugins.dat files.
> This seems to work because
>
> jar -tf iutools-core-1.0.2-jar-with-dependencies.jar | grep Log4j2Plugins
>
>
> produces an empty list.
>
> So I think the problem lies elsewhere.

The removal of the `Log4j2Plugins.dat` files is exactly the source of
the problem. Log4j2 uses these files to load the list of available
plugins (like the Log4j 1.2 configuration factories), if it does not
find them it falls back to scanning the
`org.apache.logging.log4j.core` package. The plugins from
`log4j-1.2-api` are not in this package. Instead of deleting these
files you should merge them using the Maven shade plugin proposed by
Ralph.

As an alternative you can replace the `maven-shade-plugin` with the
`spring-boot-maven-plugin` that creates single JAR file applications
without squashing all jars into one:
https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#goals-repackage

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Shutting down Log4j2 in a JavaEE environment that does not include servlets

[Piotr P. Karwasz]

Hi René,

On Fri, 10 Jun 2022 at 16:36, Schindler, René
 wrote:
> Therefore we came up with this workaround:
>
> @PreDestroy
> public static void shutDown() {
> org.apache.logging.log4j.LogManager.shutdown();
>
> Configurator.reconfigure(new NullConfiguration());
> Server.unregisterMBeans();
> }
>
> It prevents the instantiation of the appenders and async loggers and 
> replacing the current config with a NullConfiguration.
> The restart still takes place, but it does not prevent the undeplyoment any 
> more (when getting rid of existing MBeans).
>
> Is there a more elegant solution, maybe getting rid of the restart in the 
> first place?

Can you add more details about your deployment? What application
server are you using?

To find out, which component reinitializes Log4j2, you can run the server with:

-Dlog4j2.debug=true -Dlog4j2.loggerContextStacktraceOnStart=true

which will log a stack trace of the call that initialized the logger context.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: ListAppender in parallel tests

[Piotr P. Karwasz]

Hi, Björn,

On Wed, 13 Apr 2022 at 17:46, Björn Kautler  wrote:
>
> I'm currently using ListAppender from log4j2-core-test, to test that
> the logging of the project does what it should do.
> For that I configured a ListAppender in the log4j2 config file that is
> used for the tests.
> In a custom global Spock extension (the test framework I use), I
> retrieve the appender
> using ListAppender.getListAppender and call clear() on it before an
> iteration starts,
> so I only get the logs written during that test and it also does not
> overflow the RAM.

The main question that has not been asked in this thread is: are your
loggers static or instance fields in the classes that you are testing?

If it is the former (the far most common scenario), the idea of a
LoggerContext per test will not work, since the logger is bound to a
LoggerContext during class initialization. You can however create
multiple list appenders and use RoutingAppender to select the correct
one during testing:


  

  

  


This configuration will get you a different list appender for each
thread, so your logic should work.

Regarding the Log4j2 unity tests, the situation is different: the
classes we test do not contain loggers, just a `StatusLogger`. While
Matt's extension that provides a different logger context per test
mostly solves the test concurrency problem, the tests that check the
`StatusLogger` output still can not be run concurrently.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: shared log4j config used by multiple tomcat webapps

[Piotr P. Karwasz]

Hi Dave,

Thank you for bringing this subject up.

On Thu, 12 May 2022 at 13:16, Dave Piper (HE/HIM)
 wrote:

> We've been using log4j for over a decade to produce logs for various
> webapps within a single tomcat instance. Some of our loggers and file
> appenders are defined within the tomcat/lib folder itself so that they're
> picked up by the common classloader and can be shared by multiple webapps.
> The intention of this was to remove the risk of separate webapp processes
> writing to the same file simultaneously and causing write issues. We also
> have per-webapp log4j config.
>
> Our file system is laid out as follows:
>
> - tomcat
> - tomcat/lib/log4j2.xml   (defines shared appenders and loggers)
> - tomcat/lib/log4j-core.jar (and other log4j jars)
> - ...
> - tomcat/webapps/mywebapp1/WEB-INF/classes/log4j2.xml  (defines appenders
> and loggers for webapp 1)
> - tomcat/webapps/mywebapp1/WEB-INF/lib/log4j-core.jar  (and other log4j
> jars)
> - ...
> - tomcat/webapps/mywebapp2/WEB-INF/classes/log4j2.xml  (defines appenders
> and loggers for webapp 2)
> - tomcat/webapps/mywebapp2/WEB-INF/lib/log4j-core.jar   (and other log4j
> jars)
> - ...
>

Can you explain in more detail your previous Log4j 1.x setup? If it was
similar to what you present here, I fail to understand how could you have a
shared set of appender instances (not appender identically configured).

This was working as designed when we were using tomcat 8 and log4j v1, but
> since moving to tomcat 9 and log4j v2 we're no longer able to load both
> config files. When log4j logging is set to debug in tomcat, catalina.out
> shows that tomcat discovers and processes the webapp-specific log4j2.xml
> files but not the one under log4j2.xml.  We can configure tomcat / log4j so
> that each webapp loads multiple config files, but we think it's only
> loading those on a per-webapp basis, I think it's not loading one shared
> XML file so we don't get shared appenders. Having log4j v2 jars in multiple
> locations is also causing various errors.
>

Due to the way classloader delegation works in servlet containers, if an
application has a copy of `log4j-api` and `log4j-core`, it can not use the
copy from the common classloader. As you remarked yourself, you can share
the configuration file, but this will just create multiple identically
configured file appenders.

In order to have a set of common appenders you need to:

1. Change the delegation model of each web application classloader to
delegate to the parent first. You can do this by adding to
`$CATALINA_BASE/conf/context.xml`:



   After this change you should be careful what you put in
`$CATALINA_BASE/lib`, since it will be shared by all applications.

 2. Configure Log4j2 to read both `log4j2.xml` files. This can be done
using the `log4j2.configurationFile` setting. For example a
`-Dlog4j2.configurationFile=${sys:catalina.base}/lib/log4j2.xml,classpath:log4j2.xml`
should work, although I would rather rename the shared configuration file.

After these changes:
 * each application will use the same copy of `log4j-core`,
 * since the default `ContextSelector` is `ClassLoaderContextSelector`,
each application will have its own logger context and configuration,
 * technically each application will have its own set of appenders, but the
`FileManager`s will be shared by all applications. Therefore each log file
will be opened only once regardless of the number of applications that use
it.

Piotr

Re: LogManager.getLogger("name") not finding custom loggers

[Piotr P. Karwasz]

Hello Stephen,

On Wed, 20 Apr 2022 at 20:03, Stephen Johns 
wrote:

> Configurator.initialize(configurationBuilder.build());
>

This only works if the `LoggerContext` has not been initialized yet. Since
every call to a `LogManager` method initializes a `LoggerContext`, it is
almost certainly too late to use `Configurator.initialize`.

Use `Configuration.reconfigure` instead, which works in all cases.

Piotr

Re: Module or Classpath

[Piotr P. Karwasz]

Hello Karthik,

On Tue, 19 Apr 2022 at 14:45, KARTHIK SHIVAKUMAR 
wrote:

> I need log4j2 to log all of the  info/debug  objects across the project.
> If i add  log4j2-core & log4j2-api to the project library,  the packages
> do not recognise the log4j objects  unless  there is a entry to
> 'module-info.java
>

Yes, if you want to use the Java Platform Module System, you need to add:

requires org.apache.logging.log4j;

to your `module-info.java` file (and put Log4j jars on the module path).

However JPMS is not very widespread, so in an initial version of your
project I wouldn't bother with modules and I would remove
`module-info.java`.

Piotr

Re: can we set log4j property 'Log4jContextSelector' per webapps war

[Piotr P. Karwasz]

Hi Ralph,

On Thu, 7 Apr 2022 at 07:50, Ralph Goers  wrote:
> Second, putting the property in log4j2.component.properties is correct. 
> However, it must only be on the classpath of the web app that needs it, not 
> in a shared directory.

If there is no `log4j-api` in the web app classpath, I would refrain
from adding a `log4j2.component.properties` to that application.

Currently most components use a single `PropertiesUtil` instance, that
is created when `log4j-api` is first initialized. If multiple
applications are using the same `log4j-api` the
`log4j.component.properties` files contained in all but the first
application will be ignored.

That is why I would propose to remove thread context classloader
support from `PropertiesUtil` in future 2.x releases or check all the
call sites of `PropertiesUtil.getProperties()` to see if they need
application specific properties or not. Of course in 3.x your
properties enhancement proposal solves most problems.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Configure composite filter for specific logger in Log4j2 via properties file

[Piotr P. Karwasz]

On Sun, 3 Apr 2022 at 21:53, Ralph Goers  wrote:
> Bugs?
>
> When it was first implemented it followed a standard format (which should
> still work). Almost immediately folks started “simplifying” it since the 
> standard
> format is cumbersome. But being cumbersome is not a bug.
>
> The biggest issue is that we simply don’t document it very well and don’t
> have a lot of examples.
>
> But I wouldn’t call having to declare the Filters element a bug.

If not bugs, then discrepancies between the XML format and the
properties format. One might expect the dot-separated fragments of a
property to correspond to the element hierarchy in XML. For example:

appender.$1.layout.pattern

might correspond to a
`/Configuration/Appenders/Console/PatternLayout/@pattern` XPath.
Discrepancies start to appear in the `` and ``
sub-trees. The former has rules of its own, while the latter:
1. does not allow an equivalent of `` (I would expect `logger.$1.$2.type = AppenderRef`,
while it is `logger.$1.appenderRef.$2`),

While `logger.$1.filter` follows the same rule as
`logger.$1.appenderRef` (i.e. introduces a "virtual" XML element for
the filters), there is a difference between the two: there can be only
one filter in a `` element. That is why it seems natural for
me to interpret `logger.$1.filter` as the equivalent of
``.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Configure composite filter for specific logger in Log4j2 via properties file

[Piotr P. Karwasz]

Hi Ralph,

On Sun, 3 Apr 2022 at 19:00, Ralph Goers  wrote:
> The enhancement you suggest would make the properties configuration different 
> than
> the other configuration formats as they all require the Filters element. This 
> is yet another
> example of why most (or all) of the log4j 2 developers really do not like the 
> properties
> format and wonder why so many people prefer it.

Yes, you are right, no need to introduce exceptions. Even if there is
only one filter, a property

logger.logger-id.filter.filter-id.type = ThresholdFilter

should be equivalent to:


  

  

Right now the `PropertiesConfigurationBuilder` does not add the
"Filters" component, so the property above gives the equivalent of:


  


This works, but fails if the user configures more than one filter (as
it would in every configuration format). BTW, I think that a property:

logger.logger-id.filter-id.type = ThresholdFilter

should also work to define a single filter. Right now it is ignored by
the `PropertiesConfigurationBuilder`.

I would go even further, regarding the properties format: no Log4j2
developer uses it and that explains why there are still many bugs in
the `PropertiesConfiguration`.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Configure composite filter for specific logger in Log4j2 via properties file

[Piotr P. Karwasz]

Hello Stamatis,

I posted a working solution on SO:

logger.t1.filter.M.type = Filters
logger.t1.filter.M.f1.type = RegexFilter
logger.t1.filter.M.f1.regex = .*SQL.*
logger.t1.filter.M.f1.onMatch = NEUTRAL
logger.t1.filter.M.f1.onMismatch = DENY
logger.t1.filter.M.f2.type = RegexFilter
logger.t1.filter.M.f2.regex = .*JPQL.*
logger.t1.filter.M.f2.onMatch = NEUTRAL
logger.t1.filter.M.f2.onMismatch = DENY

The problem is caused by two facts:
1. The `LoggerConfig` only accepts a single filter, so you have to
wrap them in a "Filters" element,
2. A `Properties` class is a `Hashtable`, so the order of the keys is random.

I believe both of them to be bugs of `PropertiesConfigurationBuilder`:
1. I interpret the "filter" prefix in the properties configuration as
an implicit "Filters" component. `addFiltersToComponent` should wrap
the filters in a "Filters" component if more than one is defined.
2. `PropertiesUtil#partitionOnCommonPrefixes` should probably return a
`TreeMap` instead of a `HashMap` to impose a deterministic order on
the filters (and other components that use this function).

You should open a JIRA ticket for this problem and since you
apparently have a PR in progress, submit your test case and a solution
as PR.

Best wishes,
Piotr

On Sat, 2 Apr 2022 at 18:44, Stamatis Zampetakis  wrote:
>
> Hi all,
>
> After many unsuccessful attempts to configure a composite filter for a
> specified logger [1] using the property syntax, I posted the following
> question on stackoverflow [2].
>
> In [1], I tried to create a unit test simulating what I would like to
> achieve but didn't manage to make it work yet. I searched in the code to
> find examples of how this can be done but couldn't find any.
>
> Any feedback would be much appreciated!
>
> Best,
> Stamatis
>
> [1]
> https://github.com/zabetak/logging-log4j2/commit/a9944885100db42f7e3ba1b3ff81d59b743d0ab7
> [2]
> https://stackoverflow.com/questions/71719354/configure-composite-filter-for-specific-logger-in-log4j2-via-properties-file

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j 1.2.x Customer Appender not used as "Plugin" by Log4j 1.2 Bridge

[Piotr P. Karwasz]

Hello Pablo,

On Tue, 29 Mar 2022 at 19:58, Pablo Rogina  wrote:
> However this warning appears (application launched with -Dlog4j2.debug=true):
> WARN StatusLogger Unable to load plugin class name
> com.mycompany.log4j.CustomAppender with key
> com.mycompany.log4j.customappender

This is an expected behavior. Most common Log4j 1.x components are
actually translated into their Log4j 2.x equivalents using
configuration builder plugins. See [1] for example. If you were using
"standard" Log4j 1.x components (e.g. org.apache.log4j.FileAppender),
this warning means that the system is using the real
org.apache.log4jFileAppender class instead of its Log4j 2.x
equivalent, which might result in poor performance.

You can actually also write such a builder plugin yourself, if you
wish to use a Log4j 1.x configuration to start your custom Log4j 2.x
appender.

Piotr

[1] 
https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-1.2-api/src/main/java/org/apache/log4j/builders/appender/RollingFileAppenderBuilder.java

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Sprint-boot 1.5.x with maven is affected por log4j vulnerability?

[Piotr P. Karwasz]

Hello Juan,

On Tue, 29 Mar 2022 at 23:00, Juan Jose Silupú Maza
 wrote:
> So, is my project affected by the LOG4J vulnerability? How do I mitigate it?

The Log4Shell vulnerability (CVE-2021-44228) concerned only the
`log4j-core` artifact developed by the Apache Logging Services
project. The `org.slf4j:log4j-over-slf4j` artifact is a Log4j 1.x
replacement developed by QOS.CH. They don't share any code, so they
don't share vulnerabilities.

However Spring Boot uses Logback as logging backend and versions of
`ch.qos.logback:logback-core` up to 1.2.7 have vulnerabilities of
their own.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Reg: Needs help on logging issues on log4j2 latest version 2.17.2

[Piotr P. Karwasz]

Hi Arulkumar,

On Thu, 24 Mar 2022 at 07:30, Arulkumar Ponnusamy 
wrote:

> However, What i noticed is, the Configurator.setLevel() method's
> Logger.getContext has a different reference id whereas the actual class's
> LoggerFactory.getLogger(class) has a different context id. I guess, because
> of this, the update does not send the notification properly so that the
> actual change is not reflected. Attached the snapshot, the first image is
> for the level setting using *Configurator.setlevel(*) and the second
> image is the actual class where actual logs are printed.
> what i noticed is, when the
>

Images are not accepted in the mailing list, please provide any code as
text.

The problem you are observing is due to the caller sensitivity of various
Log4j2 functions, which have an implicit `LoggerContext` parameter. The
change in behavior you observe is due to the fix of LOG4J-3330[1]. The fix
itself is correct, as far as I can tell, but it modifies your program's
behavior: `Configurator#setLevel` updates the `LoggerContext` associated
with the classloader of the caller.

I don't know the specifics of how WildFly manages classloaders, but IIRC
there can be multiple classloaders per application. You should consider
swapping the default `ClassLoaderContextSelector` (see
https://logging.apache.org/log4j/2.x/manual/extending.html#ContextSelector)
with something better suited for full Java EE application servers. I
believe the `JndiContextSelector` might be the right choice.

Piotr

[1] https://issues.apache.org/jira/browse/LOG4J2-3330

Re: Reg: Needs help on logging issues on log4j2 latest version 2.17.2

[Piotr P. Karwasz]

Hello Arulkumar,

What method are you using to change the logger's level? The
`Configurator.setLevel` methods are probably the most appropriate
ones.
Can you provide a minimal example of code that does not work?

Piotr

On Wed, 23 Mar 2022 at 06:43, Arulkumar Ponnusamy  wrote:
>
>  Hi all,
> I am currently working on upgrading my log4j framework from 1.x to
> 2.x(latest) and my application is deployed in the wildfly. As part of our
> application, we provide the provision to change the log level at runtime.
> Am facing a peculiar issue where the logging is working(changing the log
> level) with the 2.17.1 version whereas the same is not working with 2.17.2.
> The change of log level works only if you change it via log4j2.properties
> files.
>
> any pointers on solving this would be great help
> Thanks
> Arulkumar Ponnusamy

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Programmatic configuration all or nothing?

[Piotr P. Karwasz]

Hello Fred,

On Fri, Mar 11, 2022 at 1:29 AM Fred Eisele  wrote:
> I would like something similar.
> Maybe a way to initialize a builder with the current configuration?

An already initialized `AbstractConfiguration` can no longer be used
to initialize a configuration builder. However you can use a
CompositeConfiguration[1] to add your customization to the current
config.

Piotr

[1] 
https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/config/composite/CompositeConfiguration.html

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log4j1.x bridge error: Unable to create Lookup for bundle java.lang.ClassCastException: class org.apache.logging.log4j.core.lookup.ResourceBundleLookup

[Piotr P. Karwasz]

Hi,

On Tue, Mar 8, 2022 at 7:48 AM Pooja Pandey
 wrote:
> I am trying to migrate from log4j1.x to log4j2.17.2 using log4j1.x bridge 
> approach. I am getting below ClassCastException error message. Please let me 
> know if you have any idea how to fix this.
>
> 2022-03-08 01:41:17,023 http-nio-8088-exec-9 ERROR Unable to create Lookup 
> for bundle java.lang.ClassCastException: class 
> org.apache.logging.log4j.core.lookup.ResourceBundleLookup

Could you tell us if you have any Log4j libraries in Tomcat's
classpath (`lib` subfolder of Tomcat's installation folder)? I believe
this is related to my pet bug applied to the plugin loader:

https://issues.apache.org/jira/browse/LOG4J2-3427

If this was your situation, adding libraries to your application
certainly works, but removing them from Tomcat's server classpath also
should work.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log level settings are not working correctly and getting wrong value

[Piotr P. Karwasz]

Hello,

On Mon, Mar 7, 2022 at 3:15 PM Pooja Pandey
 wrote:
>
> From the questions you posted up to now, you use a lot of custom code 
> extending Log4j 1.x capabilities. In my personal opinion you'll spend more 
> time trying to adapt your code to use the Log4j 1.x bridge, than it would 
> require to migrate to Log4j 2.x.
>
> Almost everything is working in my application now except this "level" 
> setting. Please let me know if you have any idea how to fix this stuff.

Since you want to log messages that are less specific than the level
in the configuration file **or** less specific that a custom level you
set up programmatically, you should look into the global filter:

https://logging.apache.org/log4j/2.x/manual/filters.html

>From the documentation: "Events that are rejected by these filters
will not be passed to loggers for further processing. Once an event
has been accepted by a Context-wide filter it will not be evaluated by
any other Context-wide Filters nor will the Logger's Level be used to
filter the event. " The `Filter` interface [1] has many methods, but
if I am not wrong, you are interested in the `filter(Logger, Level,
Object, Throwable)` method. You can extend `AbstractFilter` for a
default implementation of the remaining methods.

[1] 
https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/Filter.html

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log level settings are not working correctly and getting wrong value

[Piotr P. Karwasz]

Hello Pooja,

On Mon, Mar 7, 2022 at 1:40 PM Pooja Pandey
 wrote:
>
> -> If I recall correctly, you are using a custom `Logger` class. My guess is 
> that you overrode the `getEffectiveLevel()` with some custom logic.
>
> Yes Piotr, you are correct. I am overriding this method in my custom logger 
> as below. Do you think this could be the problem??
>
>@Override
>public Level getEffectiveLevel() {
>Level configuredLevel = super.getEffectiveLevel();
>...
>Level currLevel = myLevel.get();
>...
>if (currLevel.isGreaterOrEqual(configuredLevel))
>return configuredLevel;
>return currLevel;
>}

That is your problem: your function is returning the smallest between
`configuredLevel` and your custom `currLevel` using Log4j 1.x
semantics (i.e. DEBUG is smaller than ERROR).

I think we are having an XY communication problem [1]: my guess is
that your legacy code overrode `getEffectiveLevel` to influence which
messages will be logged and which won't. That would work in Log4j 1.x,
but the bridge has different implementation details (look at the
package private method `Category#maybeLog` and the public
`Category#forcedLog` filter the messages), so even if you modify
`getEffectiveLevel()`, it will have no effects on logging.

The Log4j 1.x bridge is not meant to provide binary compatibility for
applications that configure Log4j 1.x programmatically, its scope is
limited to the cases mentioned in the documentation[2]:
 1. It assures binary compatibility for applications and libraries
that use the Log4j 1.x API. By Log4j 1.x API I mean the
`Logger#error`, `Logger#warn` and similar methods,
 2. It allows users to continue using the Log4j 1.x configuration format.

Although version 2.17.2 made a huge step forward towards a drop-in
Log4j 1.x replacement (mostly due to Gary), that is not among the
component's goals.

>From the questions you posted up to now, you use a lot of custom code
extending Log4j 1.x capabilities. In my personal opinion you'll spend
more time trying to adapt your code to use the Log4j 1.x bridge, than
it would require to migrate to Log4j 2.x.

Piotr

[1] https://en.wikipedia.org/wiki/XY_problem
[2] https://logging.apache.org/log4j/2.x/manual/migration.html

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Log level settings are not working correctly and getting wrong value

[Piotr P. Karwasz]

Hello Pooja,

On Mon, Mar 7, 2022 at 11:23 AM Pooja Pandey
 wrote:
> I think there is something wrong with Log4j1.x bridge level handling when 
> migrating from log4j1.x to log4j2.x.
>
> Issue: In my config file, log level is set to "Error",  but with log4j1.x 
> bridge log level is getting calculated as DEBUG. I think this is since in 
> log4j1.x from FATAL to DEBUG level integer value decreases as shown below but 
> in log4j2.x from FATAL to DEBUG integer value increases as shown below.

The order of Log4j 2.x numerical levels is the inverse of the Log4j
1.x order. However, that should have no influence on the result of
`org.apache.log4j.Category#getEffectiveLevel()`, if that is the
function you are referring to.

If I recall correctly, you are using a custom `Logger` class. My guess
is that you overrode the `getEffectiveLevel()` with some custom logic.
Be aware that in the Log4j 1.x bridge the field `Category#level` is
almost always `null`, while `Category#getLevel()` is an alias for
`Category#getEffectiveLevel()` (never `null`).

If that is not the case, can you run your application with
`-Dlog4j2.debug=true` and send you configuration file and the output
of the status logger (it's printed to the application's standard
error)?

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper cannot be cast to org.apache.log4j.FileAppender

[Piotr P. Karwasz]

On Sat, Mar 5, 2022 at 10:50 PM Gary Gregory  wrote:
> This is a bit tricky, the API is typed to return an Appender and that's
> what we do, not only that but it is an Appender that behaves properly IIRC.
> If we returned the wrapped Log4j 1 Appender and you call it, the wrong
> thing will happen IIRC.

The only problem I see in unwrapping an `AppenderAdapter` is in the
case filters are configured. Since `AppenderSkeleton` does not perform
filtering, this would cause the returned appender to behave
incorrectly. If no filters are configured (including the one created
from the `Threshold` property), we can unwrap the `AppenderAdapter`
safely.

Can you have a look at:

https://github.com/apache/logging-log4j2/pull/786

If  this solves Pooja's problem, I can merge it.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper cannot be cast to org.apache.log4j.FileAppender

[Piotr P. Karwasz]

Ralph,

On Sat, Mar 5, 2022 at 6:21 PM Ralph Goers  wrote:
> Even if getAppender() were to bypass the AppenderWrapper it would still return
> org.apache.logging.log4j.core.appender.FileAppender, not 
> org.apache.log4j.FileAppender.
> Are you proposing that getAppender return a proxy for 
> org.apache.log4j.FileAppender?

No, my proposition doesn't apply to this case. If a user wants to use
a standard Log4j 1.x appender, he should get an AppenderWrapper of the
corresponding Log4j 2.x appender: the Log4j 1.x emulation must have
its limits.

However if a user wants to use a custom appender extending
`org.apache.log4j.FileAppender`, then `getAppender` returns an
AppenderWrapper of an AppenderAdapter of the custom appender.
Converting back and forth between Log4j 1.x appenders and Log4j 2.x
appenders is a little bit too much. `getAppender` should just return
the custom appender.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper cannot be cast to org.apache.log4j.FileAppender

[Piotr P. Karwasz]

Hi Pooja,

On Sat, Mar 5, 2022 at 1:48 PM Pooja Pandey
 wrote:
> Hi Piotr,
>
> I don’t understand what is the bug?? Can you please help me with JIRA
> ticket summary and description.

The bug is that if you use a native Log4j 1.2 appender (a derivative
class of org.apache.log4j.FileAppender for example) a call to
`Logger.getAppender(String)` gives you an AppenderWrapper of an
AppenderAdapter instead of the original class. Such useless
encapsulations should not be present, but apparently we missed some.
Summarizing "Log4j 1.x bridge Logger.getAppender returns a wrapped
AppenderAdapter"
In the Jira ticket just describe your exact situation: are you using a
configuration file or are you adding the appenders in code? Are you
always using a LoggerFactory?
My wild guess is that you configure a subclass of
org.apache.log4j.FileAppender (let's call it com.example.FileAppender)
in a configuration file. In your code you call `Logger.getAppender()`
and you get an AppenderWrapper instead of com.example.FileAppender. If
the guess is true, it is an easy fix.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper cannot be cast to org.apache.log4j.FileAppender

[Piotr P. Karwasz]

Hi Pooja,

On Sat, Mar 5, 2022 at 3:01 AM Pooja Pandey
 wrote:
> @Override
> public Appender getAppender(final String name) {
> AppenderWrapper appenderWrapper = (AppenderWrapper) 
> super.getAppender(name);
> return 
> ((AppenderAdapter.Adapter)appenderWrapper.getAppender()).getAppender();
> }

Thank you for this example: now I understand what is happening. This
is clearly a bug in the Log4j 1.x bridge. Please, file an issue on
JIRA.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper cannot be cast to org.apache.log4j.FileAppender

[Piotr P. Karwasz]

On Fri, Mar 4, 2022 at 7:32 PM Ralph Goers  wrote:
> I am a little surprised though as it looks like Gary added the Log4j 1.2 
> FileAppender to log4j-1.2-api but he didn’t remove the builder. If he had it 
> would have created org.apache.log4j.FileAppender as you want.

The `org.apache.log4j.FileAppender` class is useful to inherit from
it. I have successfully tested the `RollingFileAppender` from Apache
Log4j Extras as native Log4j 1.x appender (there is no builder for
this one) running through the bridge.

I don't believe we actually want to use
`org.apache.log4j.FileAppender` instead of
`org.apache.logging.log4j.core.appender.FileAppender`. I suppose that
the latter gives a better performance.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper cannot be cast to org.apache.log4j.FileAppender

[Piotr P. Karwasz]

Hi Pooja,

On Fri, Mar 4, 2022 at 10:32 AM Pooja Pandey
 wrote:
> We are calling
> Logger.getLogger(, )
>
> And in AppenderAttachableImpl aai;, this is returning  AppenderWrapper, which 
> we are trying to cast to FileAppender as we were doing when we were using 
> log4j1.x.

That will not work, since the Log4j 1.x bridge does not actually use
`org.apache.log4j.FileAppender`, but the Log4j 2.x version of this
appender.

Can you explain what is your code doing? Probably this can be more
easily obtained directly in Log4j 2.x.

Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Issues with bridge API while migrating to log4j 2

[Piotr P. Karwasz]

Hello Pavithra,

The class "org.apache.log4j.rolling.RollingFileAppender" is not part
of the `log4j` artifact, but it is part of `apache-log4j-extras`
(https://mvnrepository.com/artifact/log4j/apache-log4j-extras/1.2.17).

Can you try your original configuration:

On Mon, Feb 21, 2022 at 11:16 AM Kudethur, Pavithra (Enterprise)
 wrote:
> 
> 
>  class="org.apache.log4j.rolling.FixedWindowRollingPolicy">
>  value="${app.home.dir}/logs/app.log.%i"/>
>  value="${app.home.dir}/logs/app.log"/>
> 
> 
>  class="org.apache.log4j.rolling.SizeBasedTriggeringPolicy">
> 
> 
> 
> 
> 
> 

using the 2.17.2-SNAPSHOT release of `log4j-1.2-api`, `log4j-core` and
`log4j-api`  *and* the 1.2.17 release of `apache-log4j-extras`? I
tested locally and it worked.

The problem with the configuration above is that under the hood it
will use the original `org.apache.log4j.rolling.RollingFileAppender`
class instead of the more powerful
Log4j 2.x `org.apache.logging.log4j.core.appender.RollingFileAppender`
class. To use the latter you need to switch to a Log4j 2.x
configuration file.

>Issue1: But roll over file name is just having app.log while we want  
>filename as app.log, app.log.1, app.log.2…

This was a bug in 2.17.1.

Regards,
Piotr

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org