Re: Feature Request: Named Arguments for Structured Logging such as JSON

[Ralph Goers]

I wasn’t aware GoLang had a “standard” logger. Last time I checked GoLang’s 
logging library was awful.

Log4j 2 has supported what you want ever since Json Template Layout was added. 
See https://logging.apache.org/log4j/2.x/manual/json-template-layout.html.

To get what you want just specify a pattern (See PatterLayout) to the 
JsonTemplateLayout configuration. 

In addition, you can also include the Map fields as individual attributes. 

Here is an example configuration for the message 

"message": {
"$resolver": "pattern",
"pattern": “%K"
},


Ralph

> On Apr 7, 2024, at 9:28 AM, Clayton Wohl  wrote:
> 
> The Golang standard library lets you do this:
> 
> slog.Info("showing named arguments with structured logging",
>slog.Bool("some-bool", true),
>slog.Int("some-int", 123),
>slog.Float64("some-float64", 1.234),
>slog.String("some-string", "xyz"))
> 
> which outputs the following at runtime:
> 
> {"time":"2024-04-07T11:10:04.925291-05:00","level":"INFO","msg":"showing
> named arguments with structured
> logging","some-bool":true,"some-int":123,"some-float64":1.234,"some-string":"xyz"}
> 
> I'd like to do this in Java. This seems to be a fairly common use
> case. Log4j's API doesn't seem to offer this. The closest I can get
> is:
> 
> Logger logger = LogManager.getLogger();
> 
> logger.info(new MapMessage()
>.with("someInt", 123)
>.with("someFloat", 1.23456)
>.with("someBool", true)
>.with("someString", "abc"));
> 
> which outputs the following at runtime. Notice that it just converted
> the MapMessage to a string and put that in the JSON message field.:
> 
> {"@timestamp":"2024-04-07T16:26:21.232Z","ecs.version":"1.2.0","log.level":"INFO","message":"someBool=\"true\"
> someFloat=\"1.23456\" someInt=\"123\"
> someString=\"abc\"","process.thread.name":"main","log.logger":"demo.Main"}
> 
> Is it possible that log4j3 offer something like what Golang's slog does?
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Wrapped exceptions

[Ralph Goers]

Unfortunately, the ScriptFilter won’t solve the world’s problems. I would 
imagine there are plenty of environments that disallow scripting in their 
production environment.

That said, I think we can do better than creating a new Filter for every thing 
to be tested.

Ralph

> On Apr 5, 2024, at 12:24 AM, Volkan Yazıcı  wrote:
> 
> If a user can simply solve this using a `ScriptFilter`, I am not keen on
> adding a custom filter to support this use case out of the box – in
> particular, when the user themselves signals "a poor design" on the
> application side.
> 
> I am in favor of making the custom filter implementation process as
> frictionless as possible, instead of making them a part of the default
> distribution. I think `PatternLayout` and `JsonTemplateLayout` are good
> examples of this principle – we stopped serving structures, but enabled
> users to serve themselves instead.
> 
> On Thu, Apr 4, 2024 at 10:46 PM Piotr P. Karwasz 
> wrote:
> 
>> 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
>> 
>> 


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

Re: Wrapped exceptions

[Ralph Goers]

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.

We haven’t implemented a Filter to do this but I would imagine it could easily 
be done. I would imagine it would:
a) let you specify a list of Exception classes and the Filter Result on a match 
or mismatch.
b)  allow the Result to be specified if no Exception is in the LogEvent.

Ralph

> On Apr 4, 2024, at 8:20 AM, Robert Egan  wrote:
> 
> I am currently working with an application that wraps every exception in a
> general exception. The problem is, there are some errors I can address
> (configuration errors, user errors, etc) and some I cannot address (network
> errors, database errors, etc). But they are all wrapped in the general
> exception.
> 
> I would like to ACCEPT only on the wrapped exceptions I can address and
> DENY the ones I cannot address. Can this be done simply through the log4j2
> configuration files, or will I need to create a custom filter?
> 
> Robert Egan


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

Re: Dynamic loggers/appenders

[Ralph Goers]

If you are creating separate LoggerContext’s then every one of them can have 
its own configuration. The LoggerContext has an externalMap that you can add 
items to. You could then create a Lookup to retrieve elements from the external 
Map to resolve references in a common configuration file shared by all the 
LoggerContext instances.  As you note though, all the relevant classes will 
have to reference “dynamic” Loggers, not ones associated with the Class or 
instance, or else the will associated with the LoggerContext used when the 
Class or instance was instantiated. However, they can all use the same Logger 
name.

Ralph

> On Feb 28, 2024, at 4:30 PM, NH Rao  wrote:
> 
> Greetings,
> 
> We are in the midst of tech stack upgrade and have upgraded to log4j
> version 2.23.0. I am checking if I can do things differently or in a better
> way.
> 
> We have an application not web application, but good old java/jar
> application. It receives "jobs/tasks" on MQ queues. Each job can create
> large number of log entries. We want to have separation of logs for each
> logs.
> 
> Currently we use routers in the xml config file. This mostly works, as long
> as developer remembers to set the right route values for the thread.
> 
> I'd like to do this programmatically as we have a need for splitting logs
> even more. Each class can request logger based on task id and type of log
> and log to that logger.
> 
> I am creating a new LoggerContext with task id as name. As application
> requests the loggers, I am creating the appenders and adding it to
> loggers.  At the end of task, we basically close all the taks specific
> appenders. This works the way I want it to work. However
> method org.apache.logging.log4j.core.Logger.addAppender(Appender) says not
> exposed as public API.
> 
> Is there any better way to achieve what I want to do without using routes?
> 
> Regards,
> 
> Niranjan


-
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

[Ralph Goers]

One thing nobody else mentioned. Given that 3.x requires Java 17 you can be 
assured that we will continue to support 2.x until Java 11s usage drops down 
under 10% (or possibly lower) based on the usage surveys. This is the same 
approach we have had with previous JDK versions. I would not expect that to 
happen for several years. As was also mentioned, our goal is to minimize the 
impact for users switching from 2.x to 3.x. 

Ralph

> On Jan 10, 2024, at 7:53 AM, Mickael Maison  wrote:
> 
> Hi,
> 
> 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?
> 
> 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.
> 
> Also the website states log4j3 will require Java 11 [0] but looking at
> the latest published artifacts [1], it looks like it instead requires
> Java 17 instead. Apache Kafka still supports Java 11 so we can't
> directly adopt log4j3.
> 
> Thanks,
> Mickael
> 
> 0: https://logging.apache.org/log4j/3.x/#requirements
> 1: https://logging.apache.org/log4j/3.x/download.html
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Property substitution doesn't work in log4j2 xml config

[Ralph Goers]

I’d need to see the rest of your main. For example does it declare a Logger? If 
so where is it in relation to the static block?

Ralph

> On Oct 30, 2023, at 7:25 AM, Alex Orlov  wrote:
> 
> 
> Hi all,
>  
> I use log4j 2.21.1. This is my xml config file:
>  
> 
> 
> 
>  immediateFlush="true" append="false">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> This is a piece of my MainClass:
>  
> public final class MainClass {
> 
> static {
> SimpleDateFormat dateFormat = new SimpleDateFormat("-MM-dd 
> hhmmss");
> System.setProperty("foo.test", dateFormat.format(new Date()));
> }
> 
> .
> }
>  
> However, the generated log file is `log-${sys:foo.test}.txt`. I mean:
>  
> user@pc:~/Temp/log$ ls
> 'log-${sys:foo.test}.txt'
>  
> According to docs 
> https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution
>  my solution must work but it doesn't. Could anyone say how to fix it?
>  
>  
> --
> Best regards, Alex Orlov


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

Re: Adding more than one syslog appenders with different hostname and port at runtime

[Ralph Goers]

;.addAttribute("level", Level.DEBUG));
>> 
>> builder.add(syslogAppender);
>> 
>> Configuration config = builder.build();
>>RoutingAppender.Builder routingBuilder = RoutingAppender.newBuilder();
>>routingBuilder.setConfiguration(config);
>> routingBuilder.setName("RoutingConfig");
>> 
>> Node node = null;
>> Route[] routeList = new Route[1];
>> routeList[0] = Route.createRoute("syslog", "client1", node);
>> 
>> routingBuilder.withRoutes(
>> Routes.newBuilder().withPattern("$${ctx:module}")
>> .withRoutes(routeList)
>> .build());
>> 
>> RoutingAppender routingAppender = routingBuilder.build();
>> routingAppender.start();
>> config.addAppender(routingAppender);
>>     builder.add(builder.newLogger("RoutingLogger", Level.DEBUG)
>>   .add(builder.newAppenderRef("RoutingConfig"))
>>   .addAttribute("additivity", false));
>> config = builder.build();
>> config.addLogger("RoutingLogger",
>> config.getLoggerConfig("RoutingLogger"));
>> Configurator.reconfigure(config);
>> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>> ctx.updateLoggers();
>> 
>> Logger logger = LogManager.getLogger("RoutingLogger");
>> 
>> ThreadContext.put("module", "client1");
>> logger.info("message from client");
>> logger.error("message form client error");
>> ThreadContext.remove("module");
>> 
>> On Thu, Oct 19, 2023 at 2:27 PM Ganesh S  wrote:
>> 
>>> Is there any reference for creating routing appender programmatically ?
>>> 
>>> On Thu, Oct 19, 2023, 9:35 AM Ralph Goers 
>>> wrote:
>>> 
>>>> Why are you doing it this way? Can you not just use the RoutingAppender?
>>>> https://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender
>>>> 
>>>> Ralph
>>>> 
>>>>> On Oct 18, 2023, at 8:50 PM, Ganesh S 
>>>> wrote:
>>>>> 
>>>>> Hello,
>>>>> I'm trying to create different logger with different hostname and port
>>>> for
>>>>> different client requests to the server.
>>>>> If a new client request comes, I will store the information in the
>>>> thread
>>>>> local object and based on the information I need to append a new logger
>>>>> object to the existing configuration object using
>>>> CompositeConfiguration
>>>>> and update loggers in the logger context.
>>>>> I'm using the name of the logger object not to have a package level
>>>>> hierarchy but just as a named (client name) logger.
>>>>> 
>>>>> Currently I'm getting the below error when I try to append new syslog
>>>> using
>>>>> CompositeConfiguration
>>>>> at the line
>>>>> logContext.reconfigure(compositeConfiguration);
>>>>> 
>>>>> ERROR StatusConsoleListener Appender references must contain a
>>>> reference
>>>>> ERROR StatusConsoleListener Null object returned for AppenderRef in
>>>> Logger.
>>>>> ERROR StatusConsoleListener No appender name provided
>>>>> ERROR StatusConsoleListener Could not create plugin of type class
>>>>> org.apache.logging.log4j.core.appender.SyslogAppender for element
>>>> Syslog
>>>>> org.apache.logging.log4j.core.config.ConfigurationException: Arguments
>>>>> given for element Syslog are invalid: field 'name' has invalid value
>>>> 'null'
>>>>> at
>>>>> 
>>>> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.injectFields(PluginBuilder.java:199)
>>>>> .
>>>>> at
>>>>> 
>>>> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:621)
>>>>> at
>>>>> 
>>>> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:715)
>>>>> ERROR StatusConsoleListener Null object returned for Syslog in
>>>> Appenders.
>>>>> 
>>>>> 
>>>>> Below is my implementation
>>>>> 
>>>>> Configurati

Re: Adding more than one syslog appenders with different hostname and port at runtime

[Ralph Goers]

Why are you doing it this way? Can you not just use the RoutingAppender? 
https://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender

Ralph

> On Oct 18, 2023, at 8:50 PM, Ganesh S  wrote:
> 
> Hello,
> I'm trying to create different logger with different hostname and port for
> different client requests to the server.
> If a new client request comes, I will store the information in the thread
> local object and based on the information I need to append a new logger
> object to the existing configuration object using CompositeConfiguration
> and update loggers in the logger context.
> I'm using the name of the logger object not to have a package level
> hierarchy but just as a named (client name) logger.
> 
> Currently I'm getting the below error when I try to append new syslog using
> CompositeConfiguration
> at the line
> logContext.reconfigure(compositeConfiguration);
> 
> ERROR StatusConsoleListener Appender references must contain a reference
> ERROR StatusConsoleListener Null object returned for AppenderRef in Logger.
> ERROR StatusConsoleListener No appender name provided
> ERROR StatusConsoleListener Could not create plugin of type class
> org.apache.logging.log4j.core.appender.SyslogAppender for element Syslog
> org.apache.logging.log4j.core.config.ConfigurationException: Arguments
> given for element Syslog are invalid: field 'name' has invalid value 'null'
> at
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.injectFields(PluginBuilder.java:199)
> .
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:621)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:715)
> ERROR StatusConsoleListener Null object returned for Syslog in Appenders.
> 
> 
> Below is my implementation
> 
> ConfigurationBuilder builder1 =
> ConfigurationBuilderFactory.newConfigurationBuilder();
>AppenderComponentBuilder syslogAppender1 =
> builder1.newAppender("syslog", "Syslog")
>.addAttribute("protocol", "UDP")
>.addAttribute("host", hostname)
>.addAttribute("port", port1)
>.addAttribute("appName", "serviceName")
>.addAttribute("id", "serviceName")
>.addAttribute("facility", "LOCAL0")
>.addAttribute("newLine", true)
>.addAttribute("format", "RFC5424")
>.addAttribute("ignoreExceptions", false);
> syslogAppender1.add(builder1.newFilter("ThresholdFilter",
> Filter.Result.ACCEPT, Filter.Result.DENY)
> .addAttribute("level", Level.DEBUG));
> builder1.add(syslogAppender1);
> 
> builder1.add(builder1.newLogger("client1", Level.DEBUG)
>   .add(builder1.newAppenderRef("syslog"))
>   .addAttribute("additivity", false));
> Configurator.reconfigure(builder1.build());
> 
> Logger logger = LogManager.getLogger("client1");
> logger.info("client1 message1");
> 
> ConfigurationBuilder builder =
> ConfigurationBuilderFactory.newConfigurationBuilder();
> AppenderComponentBuilder syslogAppender = builder.newAppender("syslog1",
> "Syslog")
>.addAttribute("protocol", "UDP")
>.addAttribute("host", hostname)
>.addAttribute("port", port2)
>.addAttribute("appName", "serviceName")
>.addAttribute("id", "serviceName")
>.addAttribute("facility", "LOCAL0")
>.addAttribute("newLine", true)
>.addAttribute("format", "RFC5424")
>.addAttribute("ignoreExceptions", false);
> 
> syslogAppender.add(builder.newFilter("ThresholdFilter",
> Filter.Result.ACCEPT, Filter.Result.DENY)
>.addAttribute("level", Level.DEBUG));
> builder.add(syslogAppender);
> 
> builder.add(builder.newLogger("client2", Level.DEBUG)
>   .add(builder.newAppenderRef("syslog1"))
>   .addAttribute("additivity", false));
> 
> LoggerContext logContext = LoggerContext.getContext(false);
> org.apache.logging.log4j.core.config.Configuration configurationcore =
> logContext.getConfiguration();
> List configurationList = new ArrayList<>();
> if (configurationcore != null)
> configurationList.add((AbstractConfiguration) configurationcore);
> org.apache.logging.log4j.core.config.Configuration newconfig =
> builder.build();
> configurationList.add((AbstractConfiguration) newconfig);
> CompositeConfiguration compositeConfiguration = new
> CompositeConfiguration(configurationList);
> logContext.reconfigure(compositeConfiguration);
> logContext.updateLoggers();
> 
> Logger logger1 = LogManager.getLogger("client2");
> logger1.info("client2 message1");
> logger1.info("client2 message2");
> logger.info("client1 message2");
> logger1.info("client2 message3");
> logger.info("client1 message3");
> 
> 
> Thank you,
> Ganesh S

Re: Are globs or regular expressions supported in logger names in config files?

[Ralph Goers]

> On Oct 5, 2023, at 6:47 AM, Volkan Yazıcı  wrote:
> 
> Wouldn't it be possible to use an arbiter instead? For instance, you can
> use a `ScriptArbiter` that checks the package name, and if matches, passes
> the log event to your appender,

I don’t see how this accomplishes what was asked. Arbiters are evaluated when 
the configuration is constructed, not when the application is running.

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

Re: Are globs or regular expressions supported in logger names in config files?

[Ralph Goers]

> On Oct 5, 2023, at 6:13 AM, Thorsten Schöning  
> wrote:
> 
> Hi everyone,
> 
> I have many logger names following some naming convention like in the 
> following examples:
> 
> * org.example.unique_phrase.foo
> * org.example.unique_phrase.bar
> * org.example.foo.unique_phrase.bar
> * org.example.bar.unique_phrase.foo
> 
> The goal is to configure one file appender for all packages/logger names 
> containing "unique_phrase". At the same time I would like to keep the 
> possibility for more fine grained configs with possible different appenders 
> for different packages of the above example. The only solution I know of is 
> really configuring all individual (parent) logger names/packages with the 
> same appender. Would be easier if logger names would support some concept of 
> globs or regular expressions, so one might only use something like the 
> following name:
> 
> * org.example.*.unique_phrase.*
> 
> Is something like that possible, either out-of-the-box or possibly some 
> plugin or ...? Thanks!
> 

If this is what you really want then you could create a LoggerNamePatternFilter 
and configure it like


   
 
  


Ralph




-
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

[Ralph Goers]

I believe I shared my misgivings to these two modules since this was first 
brought up. I may not have said I am -1 but I definitely never said “go for it”.


Ralph

> On Sep 29, 2023, at 5:36 AM, Christian Grobmeier  wrote:
> 
> From an observer of this discussion:
> 
> And I was thinking we have had this discussion over at dev@. I am surprised 
> we have seen something which I understood as agreement and then, when we tell 
> the users about our plans, we reopen this discussion.
> 
> This must be very frustrating for Piotr who collected all the feedback, 
> crafted that message and even shared it, and is now faced with the situation 
> when he tells a wider audience that we basically tell him to start over.
> 
> On the technical note, I feel we have too many modules only few people would 
> use. We should clean up and create a place for those modules.
> 
> Unfortunately I don’t know these modules so I can’t tell, but the way we had 
> this discussion is extremely frustrating. We should continue on dev@ (again)
> 
> On Thu, Sep 28, 2023, at 22:15, Ralph Goers wrote:
>> I created the docker and Kubernetes modules. Originally my employer 
>> used them when sending data directly via TCP to a forwarder. However, 
>> we ran into reliability issues with the forwarder when doing that so we 
>> switched to writing to the console, despite benchmarks showing it is 
>> slower. But for anyone implementing something that avoids those issues 
>> this would be very relevant.  By archiving this we are basically 
>> telling users that they cannot use it any more since it will no longer 
>> be supported. For that reason I am not in favor of that for these two 
>> components.
>> 
>> Ralph
>> 
>>> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
>>> wrote:
>>> 
>>> 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 Spr

Re: Log4j module deprecation

[Ralph Goers]

I created the docker and Kubernetes modules. Originally my employer used them 
when sending data directly via TCP to a forwarder. However, we ran into 
reliability issues with the forwarder when doing that so we switched to writing 
to the console, despite benchmarks showing it is slower. But for anyone 
implementing something that avoids those issues this would be very relevant.  
By archiving this we are basically telling users that they cannot use it any 
more since it will no longer be supported. For that reason I am not in favor of 
that for these two components.

Ralph

> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
> wrote:
> 
> 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
> 


-
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

[Ralph Goers]

I answered this same question on the dev list a week ago since you apparently 
cross posted to both. Here it is again.

Your issue is related to you starting and stopping the LoggerContext while your 
application is in an unknown state.  I can think of a few ways to deal with 
this.

1. Never shutdown the LoggerContext and only use RoutingAppenders. Each 
application should set its own key for the Route so that each uses their own 
Appenders. During shutdown of the application only shutdown the Appenders that 
apply to the applications Route.
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.
3. Use the JndiContextSelector and have each application and batch job use a 
unique JNDI name. This will allow each to have its own LoggerContext. However, 
if any of the classes use static Loggers and those classes are in a ClassLoader 
shared by the application and batch jobs then those Loggers will be tied to the 
LoggerContext used when they Loggers were first obtained. So this solution may 
not completely work for you.

Ralph


> On Aug 1, 2023, at 11:09 AM, Danish Arif  wrote:
> 
> Hi Log4j2 Team,
> 
> My query is related to log4j2 working and uses of
> LogManager.getLogger(String name); method.
> 
> 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.
> 
> 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.
> 
> Above mentioned scenario's  work around is if we don't remove/stop all
> appenders and don't use shutdown() method, but is there any more
> graceful handling which can be done?
> 
> The second question to this issue Is there any solution if multiple
> instances of the same application which are agnostic to each other's
> existence, use GetLogger("SameName"); and log into files with names in
> incremental id appended dynamically. For Example App Inst1 when gets
> logger, log into MyLogFile1 and when Inst2 initiates it logs into
> MyLogFile2.
> 
> Kindly advise what can be done to handle this type of scenario when there
> is no communication between the instances and are totally independent and
> agnostic of each other.
> 
> 
> 
> Regards,
> Danish Arif


-
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-alpha1 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 3.0.0-alpha1 release!

The artifacts may be downloaded from 
https://logging.apache.org/log4j/3.x/download.html.

As the Java ecosystem has evolved, requests have been received from users, and 
the need for improved security has become more apparent, changes were 
necessariy in Log4j’s design:
• With the introduction of the Java Platform Module System (JPMS) changes 
were needed to how the various log4j modules are packaged. While not every 
log4j module is now a fully compliant JPMS module with its own module-info.java 
file, all the modules likely to be used in a JPMS environment are.
• Many optional components, such as Scripting, JNDI, JPA and JMS, have been 
moved to their own modules. This makes Log4j-core slightly smaller in 3.x and 
aids in security by not having jars with unwanted behaviors present, making 
disabling them via system properties unnecessary.
• All plugins constructed using Log4j 3.x are now located using Java’s 
ServiceLoader. This avoids many of the problems users had packaging plugins in 
"shaded" jars as that technology directly supports ServiceLoader. Plugins 
constructed using Log4j 2.x will still function in Log4j 3.x.
• Log4j’s annotation processor has been individually packaged separate from 
Log4j-core and the plugin system it enables. For applications using the module 
path this makes it easier to provide the annotation processor since it must be 
explicitly declared in those cases.
• Log4j 3.x now uses an internal dependency injection framework to allow 
plugins to be injected with instances of classes they are dependent on.
• Many system properties used by Log4j can now be set to apply to a single 
LoggerContext making configuration in application frameworks that support 
multiple applications more flexible.
• Some deprecated classes have been removed. However, every attempt has 
been made to ensure that user code compiled for Log4j 2.x will continue to 
operate with the Log4j 3.x libraries present instead.

Apache Log4j 3.0.0-alpha1 requires a minimum of Java 11 to build and run. 

For complete information on Apache Log4j 3.x, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Log4j 3.x website - https://logging.apache.org/log4j/3.x/.

Changes

Added
• Allow plugins to be created through more flexible dependency injection 
patterns. (for LOG4J2-1188 by Matt Sicker)
• Allow to force LOG4J2 to use TCCL only. (for LOG4J2-2171 by rmannibucau, 
Ralph Goers)
• Allow web lookup to access more information. (for LOG4J2-2523 by Romain 
Manni-Bucau, Ralph Goers)
• Allow web lookup of session attributes. (for LOG4J2-2688 by Ralph Goers, 
Romain Manni-Bucau)
• Add support for injecting plugin configuration via builder methods. (for 
LOG4J2-2700 by Matt Sicker)
• Add scopes API for customizing plugin instance lifecycle. (for 
LOG4J2-2852 by Matt Sicker)
• Add qualifier annotations for distinguishing instances of the same type. 
(for LOG4J2-2853 by Matt Sicker)
• Create standardized dependency injection API. This is supported in 
several plugin categories and other configurable instances previously defined 
via system properties. (for LOG4J2-2854 by Matt Sicker)
• Add conditional annotations to support more declarative binding factory 
bundle classes. (for LOG4J2-3300 by Matt Sicker)
• Add built-in JSON configuration parser for a useful structured 
configuration file format which only requires the java.base module. (for 
LOG4J2-3415 by Matt Sicker)
• Add @Ordered annotation to support plugin ordering when two or more 
plugins within the same category have the same case-insensitive name. (for 
LOG4J2-857 by Matt Sicker)

Changed
• Simplify Maven site phase and align it with the one in 2.x branch. (for 
1220 by Volkan Yazıcı)
• Update build to use Java 11 bytecode. (for 480 by Ralph Goers)
• Convert documentation into AsciiDoc format. (for LOG4J2-1802 by Matt 
Sicker)
• Rename package core.util.datetime to core.time.internal.format to clarify 
these classes are to be considered private. (for LOG4J2-2224 by Remko Popma)
• Move time-related classes from core.util to core.time. Classes considered 
private moved to core.time.internal. (for LOG4J2-2225 by Remko Popma)
• Split off Kafka support into a new module log4j-kafka. (for LOG4J2-2227 
by Gary Gregory)
• Split off ZeroMq/JeroMq support into a new module log4j-jeromq. (for 
LOG4J2-2228 by Gary Gregory)
• Split off SMTP support into a new module log4j-smtp. (for LOG4J2-2230 by 
Gary Gregory)
• Split off CSV layout into a new module log4j-csv. (for LOG4J2-2231 by 
Gary Gregory)
• Split off JMS support into a new module log4j-jms. (for LOG4J2-2232 by 
Gary Gregory)
• Split off JDBC support into a new module log4j-jdbc. (for LOG4J2-2233 by 
Gary Gregory)
• Split off Jackson-based layouts into

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

[Ralph Goers]

You are correct that log4j-to-jul routes the log4j2 API to java.util.logging. 
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. 

Ralph

> On Jun 2, 2023, at 3:13 PM, Jason Guild  wrote:
> 
> Hi All:
> 
> I have a web application that uses log4j (v2.20) which runs inside Tomcat 9.x 
> on Java 8.
> 
> Currently, the WEB-INF/log4j2.xml configuration file in the application sends 
> its output to a rolling file appender targeting a separate file on the file 
> system, but what I'd like to do is make all log4j output go to the regular 
> per-application log under ${catalina_base}/logs which is managed by the stock 
> Tomcat JULI implementation.
> 
> We now have the log4j-to-jul module which can adapt log4j 2 output back to 
> java.util.logging.
> Similar to my understanding of the purpose for log4j-to-slf4j, it seems that 
> log4j-to-jul is meant to be used as an implementation by itself for log4j-api 
> and without log4j-core.
> 
> 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.
> 
> After adding log4j-to-jul to the application classpath, I can see that it is 
> recognized:
>> Multiple logging implementations found:
>> Factory: org.apache.logging.log4j.core.impl.Log4jContextFactory, Weighting: 
>> 10
>> Factory: org.apache.logging.log4j.tojul.JULLoggerContextFactory, Weighting: 
>> 20
> 
> But then the following error is reported:
>> ERROR StatusLogger LogManager returned an instance of 
>> org.apache.logging.log4j.tojul.JULLoggerContextFactory which does not 
>> implement org.apache.logging.log4j.core.impl.Log4jContextFactory. Unable to 
>> initialize Log4j.
> 
> In org.apache.logging.core.config.Configurator, line 47 there is a 
> conditional that checks the return type of the logging implementation is-a 
> Log4jContextFactory. The problem is then that JULLoggerContextFactory 
> implements only LoggerContextFactory.
> 
> I'd like to keep my tomcat container as stock as possible. Particularly, 
> continuing to use the built-in JULI per-application logging and *not* 
> switching the entire container to use log4j as its logging implementation.
> 
> Can anyone suggest how I can use log4j-to-jul successfully for my use case?
> 
> Thanks,
> Jason
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Java 17 does not satisfy the Java 11 dependency for log4j 2.17.1

[Ralph Goers]

You will have to contact RedHat. As I said, we do not provide RPMs. You can 
either find a zipped archive of the artifacts for the release on our download 
page or you can retrieve the artifacts from the Maven Central repository. I 
have no idea what one is supposed to do with that RPM.

Ralph

> On Apr 12, 2023, at 1:17 PM, Farrell, James 
>  wrote:
> 
> I got the log4j rpm from the Red Hat website: 
> log4j-2.17.1-4.module+el8.6.0+14625+c2f2c058.noarch.rpm - Red Hat Customer 
> Portal<https://access.redhat.com/downloads/content/rhel---8/x86_64/7441/log4j/2.17.1-4.module+el8.6.0+14625+c2f2c058/noarch/fd431d51/package>
> 
> On 2023/04/12 19:46:38 Ralph Goers wrote:
>> Log4j doesn't supply an RPM of LOG4J. I'm not even sure how one could do 
>> that. What is the actual RPM and who provided it?
> 
>> 
>> Ralph
>> 
>>> On Apr 12, 2023, at 12:37 PM, Farrell, James  
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> I'm trying to install log4j 2.17.1 on RHEL 8.7 running Java 17, but rpm is 
>>> reporting an error stating that Java 11 is a required dependency to run 
>>> log4j. Is there a reason why Java 17 doesn't satisfy the Java 11 
>>> dependency? Any way I can get log4j to install running Java 17? I am 
>>> running an environment that requires Java 17 so I am unable to use a 
>>> different version, and I prefer not to run multiple versions of Java on 
>>> this system if possible.
> 
>>> 
>>> Thank you,
>>> 
>>> James Farrell
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>> 


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

Re: Java 17 does not satisfy the Java 11 dependency for log4j 2.17.1

[Ralph Goers]

Log4j doesn’t supply an RPM of LOG4J. I’m not even sure how one could do that. 
What is the actual RPM and who provided it?

Ralph

> On Apr 12, 2023, at 12:37 PM, Farrell, James 
>  wrote:
> 
> Hello,
> 
> I'm trying to install log4j 2.17.1 on RHEL 8.7 running Java 17, but rpm is 
> reporting an error stating that Java 11 is a required dependency to run 
> log4j. Is there a reason why Java 17 doesn't satisfy the Java 11 dependency? 
> Any way I can get log4j to install running Java 17? I am running an 
> environment that requires Java 17 so I am unable to use a different version, 
> and I prefer not to run multiple versions of Java on this system if possible.
> 
> Thank you,
> 
> James Farrell


-
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

[Ralph Goers]

Looking at Configurator.setLevel(String loggerName, Level level) it should do 
exactly what I described - if there is no LoggerConfig with the name specified 
one will be created and have its level set. Otherwise it sets the Level on the 
located LoggerConfig. It then calls updateLoggers. If this doesn’t work 
correctly then I would want to see the Log4j debug logs from startup to see if 
there are multiple LoggerContexts and multiple configurations.

Ralph

> On Feb 28, 2023, at 9:18 PM, Ralph Goers  wrote:
> 
> What you are running into is a fundamental difference in how Log4j 1.x worked 
> and how Log4j2 works. In Log4j 1 when you added a Logger statement to the 
> configuration it would create a “real” Logger just as if you had called 
> LogManager.getLogger(). Log4j 2.x does not do that. As Pier noted, this is so 
> log events are never lost when configuration changes are made. 
> 
> I have a suspicion here that the “loggerName” you passed in doesn’t actually 
> exist in your configuration.  The way getLoggerConfig works is that it looks 
> for a Logger defined in the configuration that exactly matches what you 
> specified - in this case “com.example.Class”.  If it doesn’t find that it 
> then strips off the last token and tries again (com.example). It repeats this 
> until it gets to the root LoggerConfig.  So if you don’t have any Loggers 
> configured that at least partially match the Logger name you provided then it 
> is going to set the level for the root LoggerConfig..
> 
> If you were to call getLogger for the same name it will only return the 
> LoggerConfig if there is an exact match, otherwise it will return null.
> 
> If you really want to change the level for a specific Logger then you have to 
> ensure that a LoggerConfig actually exists for that name.  You would first 
> call getLogger(loggerName) and if it returns null then you need to add a new 
> LoggerConfig by calling addLogger. You will need to create the LoggerConfig 
> with the appropriate Level, filters, and appenders (or let it inherit those 
> from its parents).  If it does exist then call setLevel on the existing 
> LoggerConfig. In either case you must then call updateLoggers to cause all 
> the Loggers to reassociate with the appropriate LoggerConfigs.
> 
> Ralph
> 
> 
> 
>> On Feb 28, 2023, at 12:04 PM, Christopher Schultz 
>>  wrote:
>> 
>> All,
>> 
>> I'm coming from a log4j v1.x background where this was easy to do:
>> 
>> String loggerName = "com.example.Class";
>> Logger log = LogManager.exists(loggerName);
>> if(null != log) {
>> log.setLevel(targetLevel);
>> }
>> 
>> This appears no longer to be possible -- or at least easy -- and I've seen 
>> at least two techniques on StackOverflow which result in the same behavior: 
>> the log-level threshold for *every logger everywhere* gets set to the target 
>> level.
>> 
>> For example, setting the log-level for the logger called "foo" to TRACE ends 
>> up filling my log with stuff from completely unrelated loggers/classes/etc.
>> 
>> Here is one technique[1]
>> 
>> String loggerName = "com.example.Class";
>> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>> Configuration config = ctx.getConfiguration();
>> LoggerConfig loggerConfig = config.getLoggerConfig(loggerName);
>> loggerConfig.setLevel(level);
>> ctx.updateLoggers();  // This causes all Loggers to refetch information from 
>> their LoggerConfig.
>> 
>> I tried both with and without the ctx.updateLoggers() call.
>> 
>> Here is another technique[2]:
>> 
>> Configurator.setLevel(loggerName, level);
>> 
>> This reconfigures everything just like the one above.
>> 
>> The final technique (still in the same SO question) is this:
>> 
>>   final LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>>   final Configuration config = ctx.getConfiguration();
>> 
>>   LoggerConfig loggerConfig = config.getLoggerConfig(logger.getName());
>>   LoggerConfig specificConfig = loggerConfig;
>> 
>>   // We need a specific configuration for this logger,
>>   // otherwise we would change the level of all other loggers
>>   // having the original configuration as parent as well
>> 
>>   if (!loggerConfig.getName().equals(logger.getName())) {
>>   specificConfig = new LoggerConfig(logger.getName(), level, true);
>>   specificConfig.setParent(loggerConfig);
>>   config.addLogger(logger.getName(), specificConfig);
>>   }
>>   specificConfig.setLevel(level);
>>   ctx.updateLoggers();
>> 
>> This does not seem to s

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

[Ralph Goers]

What you are running into is a fundamental difference in how Log4j 1.x worked 
and how Log4j2 works. In Log4j 1 when you added a Logger statement to the 
configuration it would create a “real” Logger just as if you had called 
LogManager.getLogger(). Log4j 2.x does not do that. As Pier noted, this is so 
log events are never lost when configuration changes are made. 

I have a suspicion here that the “loggerName” you passed in doesn’t actually 
exist in your configuration.  The way getLoggerConfig works is that it looks 
for a Logger defined in the configuration that exactly matches what you 
specified - in this case “com.example.Class”.  If it doesn’t find that it then 
strips off the last token and tries again (com.example). It repeats this until 
it gets to the root LoggerConfig.  So if you don’t have any Loggers configured 
that at least partially match the Logger name you provided then it is going to 
set the level for the root LoggerConfig..

If you were to call getLogger for the same name it will only return the 
LoggerConfig if there is an exact match, otherwise it will return null.

If you really want to change the level for a specific Logger then you have to 
ensure that a LoggerConfig actually exists for that name.  You would first call 
getLogger(loggerName) and if it returns null then you need to add a new 
LoggerConfig by calling addLogger. You will need to create the LoggerConfig 
with the appropriate Level, filters, and appenders (or let it inherit those 
from its parents).  If it does exist then call setLevel on the existing 
LoggerConfig. In either case you must then call updateLoggers to cause all the 
Loggers to reassociate with the appropriate LoggerConfigs.

Ralph



> On Feb 28, 2023, at 12:04 PM, Christopher Schultz 
>  wrote:
> 
> All,
> 
> I'm coming from a log4j v1.x background where this was easy to do:
> 
> String loggerName = "com.example.Class";
> Logger log = LogManager.exists(loggerName);
> if(null != log) {
>  log.setLevel(targetLevel);
> }
> 
> This appears no longer to be possible -- or at least easy -- and I've seen at 
> least two techniques on StackOverflow which result in the same behavior: the 
> log-level threshold for *every logger everywhere* gets set to the target 
> level.
> 
> For example, setting the log-level for the logger called "foo" to TRACE ends 
> up filling my log with stuff from completely unrelated loggers/classes/etc.
> 
> Here is one technique[1]
> 
> String loggerName = "com.example.Class";
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> Configuration config = ctx.getConfiguration();
> LoggerConfig loggerConfig = config.getLoggerConfig(loggerName);
> loggerConfig.setLevel(level);
> ctx.updateLoggers();  // This causes all Loggers to refetch information from 
> their LoggerConfig.
> 
> I tried both with and without the ctx.updateLoggers() call.
> 
> Here is another technique[2]:
> 
> Configurator.setLevel(loggerName, level);
> 
> This reconfigures everything just like the one above.
> 
> The final technique (still in the same SO question) is this:
> 
>final LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>final Configuration config = ctx.getConfiguration();
> 
>LoggerConfig loggerConfig = config.getLoggerConfig(logger.getName());
>LoggerConfig specificConfig = loggerConfig;
> 
>// We need a specific configuration for this logger,
>// otherwise we would change the level of all other loggers
>// having the original configuration as parent as well
> 
>if (!loggerConfig.getName().equals(logger.getName())) {
>specificConfig = new LoggerConfig(logger.getName(), level, true);
>specificConfig.setParent(loggerConfig);
>config.addLogger(logger.getName(), specificConfig);
>}
>specificConfig.setLevel(level);
>ctx.updateLoggers();
> 
> This does not seem to set the log level for all loggers to e.g. TRACE but it 
> also doesn't seem to set the actual logger. (I can see e.g. DEBUG and TRACE 
> logs from other loggers, so it's not an issue with the appender).
> 
> 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.
> 
> Thanks,
> -chris
> 
> 
> [1] Adapted from https://stackoverflow.com/a/23434603/276232
> [2] Adapted from https://stackoverflow.com/a/44678752/276232
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: [EXTERNAL] Plugin package scanning deprecation

[Ralph Goers]

That is a good plan. We marked it as deprecated as a warning, but it will not 
be removed in a 2.x release.

Ralph

> On Feb 24, 2023, at 1:44 PM, Kish, Robert [AG] 
>  wrote:
> 
> Thanks for the responses! I won't worry about having to change my code / 
> environment setup now and will instead ignore the deprecation warning and 
> wait for the eventual 3.0 release.
> 
> -Original Message-
> From: Ralph Goers 
> Sent: Friday, February 24, 2023 03:40 PM
> To: Log4J Users List 
> Subject: [EXTERNAL] Re: Plugin package scanning deprecation
> 
> Note - the annotation processor will still be required in 3.0. Instead of 
> generating a Log4jplugins.dat file it generates a Java class file. That class 
> file is loaded via the ServliceLoader.
> 
> Also, Log4j 3 requires Java 11 and supports JPMS. With JPMS applications have 
> to specify the annotation processor(s) to run as they are not automatically 
> loaded from the module path. The annotation processor is also in its own jar 
> in Log4j 3.
> 
> Package scanning is just too slow to be acceptable at run time.
> 
> Ralph
> 
> CONFIDENTIALITY NOTICE: The information contained in this communication from 
> New Jersey Department of Agriculture is privileged and confidential and is 
> intended for the sole use of the persons or entities who are the addressees. 
> If you are not an intended recipient of this email, the dissemination, 
> distribution, copying or use of the information it contains is strictly 
> prohibited. If you have received this communication in error, please 
> immediately contact the sender of this email message to arrange for the 
> return of this information.
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Plugin package scanning deprecation

[Ralph Goers]

Note - the annotation processor will still be required in 3.0. Instead of 
generating a Log4jplugins.dat file it generates a Java class file. That class 
file is loaded via the ServliceLoader.  

Also, Log4j 3 requires Java 11 and supports JPMS. With JPMS applications have 
to specify the annotation processor(s) to run as they are not automatically 
loaded from the module path. The annotation processor is also in its own jar in 
Log4j 3.

Package scanning is just too slow to be acceptable at run time. 

Ralph

> On Feb 24, 2023, at 1:22 PM, Matt Sicker  wrote:
> 
> We’re removing it in 3.0. In 3.0, plugins are instead loaded via 
> ServiceLoader from the JDK. The annotation processor was updated to generate 
> the service classes with the plugin metadata, though that can be created 
> manually if necessary. This is related to supporting Java modules which don’t 
> work very well with classpath scanning.
> 
>> On Feb 24, 2023, at 2:00 PM, Kish, Robert [AG] 
>>  wrote:
>> 
>> I see with version 2.20 that plugin package scanning is now marked for 
>> deprecation. This sounds great except for my use case of running a Tomcat 
>> web application inside of Eclipse. Eclipse compiles the code itself and 
>> launches Tomcat for ease of development. But this internal compiler has no 
>> clue about the Log4j2Plugins.dat file. I'm just at a loss for how to get 
>> this thing to work in this situation. We use maven to build our application 
>> but that doesn't really apply here as Eclipse's internal compiler is doing 
>> its own thing, and doesn't run all the plugins that one would place in the 
>> pom.xml.
>> 
>> Does anyone have any suggestions on what to do about this when the package 
>> scanning is finally removed?
>> CONFIDENTIALITY NOTICE: The information contained in this communication from 
>> New Jersey Department of Agriculture is privileged and confidential and is 
>> intended for the sole use of the persons or entities who are the addressees. 
>> If you are not an intended recipient of this email, the dissemination, 
>> distribution, copying or use of the information it contains is strictly 
>> prohibited. If you have received this communication in error, please 
>> immediately contact the sender of this email message to arrange for the 
>> return of this information.
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.20.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html.

This release primarily contains bug fixes and minor enhancements.

Due to a break in compatibility in the SLF4J binding, Log4j now ships with two 
versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with 
SLF4J 1.7.x and earlier and log4j-slf4j2-impl should be used with SLF4J 2.x and 
later. SLF4J-1.8.x is no longer supported as there were never any GA versions 
of that. Note that while log4j-slf4j-impl has a dependency on slf4j 1.7.25 in 
order to not break compatibility for users, newer versions of SLF4J 1.7 may be 
used instead.

The Log4j 2.20.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

Apache Log4j 2.20.0 requires a minimum of Java 8 to build and run. Log4j 2.12.4 
is the last release to support Java 7. Log4j 2.3.2 is the last release to 
support Java 6. Java 6 and Java 7 are no longer supported by the Log4j team.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Log4j 2 website - https://logging.apache.org/log4j/2.x/.

Changes

Added
• Add support for timezones in RollingFileAppender date pattern (for 
LOG4J2-1631 by Piotr P. Karwasz, Danas Mikelinskas)
• Add LogEvent timestamp to ProducerRecord in KafkaAppender (for 
LOG4J2-2678 by Piotr P. Karwasz, Federico D’Ambrosio)
• Add PatternLayout support for abbreviating the name of all logger 
components except the 2 rightmost (for LOG4J2-2785 by Ralph Goers, Markus Spann)
• Removes internal field that leaked into public API. (for LOG4J2-3615 by 
Piotr P. Karwasz)
• Add a LogBuilder#logAndGet() method to emulate the Logger#traceEntry 
method. (for LOG4J2-3645 by Piotr P. Karwasz)

Changed
• Simplify site generation (for 1166 by Volkan Yazıcı
• Switch the issue tracker from JIRA to GitHub Issues (for 1172 by Volkan 
Yazıcı)
• Remove liquibase-log4j2 maven module (for 1193 by StevenMassaro)
• Fix order of stacktrace elements, that causes cache misses in 
ThrowableProxyHelper. (for 1214 by alex-dubrouski, Piotr P. Karwasz)
• Switch from com.sun.mail to Eclipse Angus. (for LOG4J2-3554 by Oleh 
Astappiev, Piotr P. Karwasz)
• Add Log4j2 Core as default runtime dependency of the SLF4J2-to-Log4j2 API 
bridge. (for LOG4J2-3601 by afs, Piotr P. Karwasz)
• Replace maven-changes-plugin with a custom changelog implementation (for 
LOG4J2-3628 by Volkan Yazıcı)

Deprecated
• Deprecate support for package scanning for plugins (for LOG4J2-3644 by 
Ralph Goers)

Fixed
• Copy programmatically supplied location even if includeLocation="false". 
(for 1197 by Piotr P. Karwasz)
• Eliminate status logger warning, when disableAnsi or noConsoleNoAnsi is 
used the style and highlight patterns. (for 1202 by wleese, Piotr P. Karwasz)
• Fix detection of location requirements in RewriteAppender. (for 1274 by 
amirhadadi, Piotr P. Karwasz)
• Replace regex with manual code to escape characters in Rfc5424Layout. 
(for 1277 by adwsingh)
• Fix java.sql.Time object formatting in MapMessage (for LOG4J2-2297 by 
Ralph Goers)
• Fix previous fire time computation in CronTriggeringPolicy (for 
LOG4J2-3357 by Ralph Goers)
• Correct default to not include location for AsyncRootLoggers (for 
LOG4J2-3487 by Ralph Goers, Dave Messink)
• Lazily evaluate the level of a SLF4J LogEventBuilder (for LOG4J2-3598 by 
Piotr P. Karwasz)
• Fixes priority of Legacy system properties, which are now back to having 
higher priority than Environment variables. (for LOG4J2-3615 by adwsingh, Piotr 
P. Karwasz)
• Protects ServiceLoaderUtil from unchecked ServiceLoader exceptions. (for 
LOG4J2-3624 by Piotr P. Karwasz)
• Fix Configurator#setLevel for internal classes (for LOG4J2-3631 by Piotr 
P. Karwasz, Jeff Thomas)
• Fix level propagation in Log4jBridgeHandler (for LOG4J2-3634 by Piotr P. 
Karwasz, Marcel Koch)
• Disable OsgiServiceLocator if not running in OSGI container. (for 
LOG4J2-3642 by adwsingh, Piotr P. Karwasz)
• When using a Date Lookup in the file pattern the current time should be 
used. (for LOG4J2-3643 by Ralph Goers)
• Fixed LogBuilder filtering in the presen

Re: log4j2 API and JUL logging framework

[Ralph Goers]

Volkan,

I am not sure what question you are answering but it doesn’t look like the 
question that was asked. To answer his question you would need to replace 
log4j-core with log4j-to-jul as a dependency.

Ralph

> On Jan 25, 2023, at 2:05 AM, Volkan Yazıcı  wrote:
> 
> That is a really good question addressing a concern that should be shared
> by every single Java library developer out there, Usha. We sadly don't have
> an official answer to this – we should and maybe who knows, you can
> contribute that to the Log4j manual! But let me share my take on the matter.
> 
> Libraries should only depend on logging APIs (SLF4J, Log4j, JUL, JCL, JPL,
> etc.) and only provide an implementation (Log4j, Logback, etc.) for their
> tests. Let me try to get it as concrete as possible by sharing what you
> need to have in your `pom.xml`:
> 
> 
>  
> 
>
>  org.apache.logging.log4j
>  log4j-bom
>  ${log4j2.version}
>  pom
>  import
>
> 
>  
> 
> 
> 
> 
>  
>org.apache.logging.log4j
>log4j-api
>  
> 
>  
>org.apache.logging.log4j
>log4j-core
>test
>  
> 
>  
> 
> 
> 
> Next you add a minimal `log4j2.xml` to `src/test/resources` and you are
> done.
> 
> It is the responsibility of the application which will be glueing all these
> libraries together to decide on where to and how to bind all these logging
> APIs. As a matter of fact, many modern application frameworks provide
> goodies to save you from that burden; consider `spring-boot-starter-log4j2`.
> 
> On Wed, Jan 25, 2023 at 12:01 AM Usha Nayak  wrote:
> 
>> Hello All,
>> 
>> As a library owner, if I were to use the log4j2 API and the application
>> that uses my library has a java.util.logging ( JUL ) framework.
>> 
>> What adapter or routing jars will be needed at runtime by application such
>> that all the logs, both from the library and the application, end up using
>> the same logging framework implementation (JUL) ?
>> 
>> Any help greatly appreciated
>> 
>> Thanks
>> 


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

Re: log4j2 API and JUL logging framework

[Ralph Goers]

The log4j-jul module is what maps anyone coding to java.util.logging to use 
Log4j 2 as the recommendation. The log4j-to-jul module is used when Log4j 2 is 
the API and java.util.logging is the implementation.

Note that log4j-to-jul is fairly new. It was introduced by LOG4J2-3282 in Jira 
in Jan 2022 as a user contribution, although it has had a few minor 
modifications since then.

Ralph

> On Jan 24, 2023, at 6:44 PM, Usha Nayak  wrote:
> 
> Thank you all for your response.
> 
> I did look through the documentation.  However, the impression I got from the 
> 'Using log4j2 with JUL' section was that log4j2 is used as a logging 
> framework (application uses JUL lib and with 'log4j-jul' bridge connects to 
> log4j2 logging framework) . In my case, it's an opposite requirement.
> 
> I did come across below though in FAQ section:
> 
> 
> 
> 
> 
> which makes me think that an application ( who are consumers of my lib, which 
> is based of log4j2 API ) will need log4j-to-slf4j-2.x.jar, 
> slf4j-api.jar,slf4j-jdk14.jar (jul binding for slf4j delegating all slf4j 
> calls to be  JUL ) 
> 
> On the other hand, if my lib were to be based of slf4j API, then the 
> applications (consumers of my lib ) will only need slf4j-jdk14.jar 
> 
> My understanding is a library should be based on only an api jar and nothing 
> else and it's an application that'll provide the bindings. With the log4j2 
> API, there are quite a few bindings that applications will need to be aware 
> of. Am I missing something?
> 
> Thanks. Regards
> 
>  
> 
> 
> 
> 
> On Tue, Jan 24, 2023 at 7:31 PM Gary Gregory  > wrote:
>> How about https://logging.apache.org/log4j/2.x/manual/api-separation.html
>> 
>> Gary
>> 
>> On Tue, Jan 24, 2023, 18:31 Matt Sicker > > wrote:
>> 
>> > That’s the log4j-to-jul module. I can’t find a link on the site, but
>> > here’s the module overview page:
>> > https://logging.apache.org/log4j/2.x/log4j-to-jul/index.html
>> >
>> > > On Jan 24, 2023, at 5:01 PM, Usha Nayak > > > > wrote:
>> > >
>> > > Hello All,
>> > >
>> > > As a library owner, if I were to use the log4j2 API and the application
>> > > that uses my library has a java.util.logging ( JUL ) framework.
>> > >
>> > > What adapter or routing jars will be needed at runtime by application
>> > such
>> > > that all the logs, both from the library and the application, end up
>> > using
>> > > the same logging framework implementation (JUL) ?
>> > >
>> > > Any help greatly appreciated
>> > >
>> > > Thanks
>> >
>> >

Re: PatternLayout Vs JsonTemplateLayout/JsonLayout Performance Comparision

[Ralph Goers]

Personally, I wouldn’t recommend using PatternLayout to render JSON. There are 
too many things that can go wrong and it is very limiting to do that.

Ralph

> On Nov 16, 2022, at 10:22 AM, Carter Kozak  wrote:
> 
> On Wed, Nov 16, 2022, at 12:09, Christopher Schultz wrote:
>> Is it even possible to use PatternLayout safely with JSON-encoded data? 
>> What if you log a username which contains a " character? Won't that 
>> completely break your JSON?
> 
> This can be done using the %encode pattern described in the documentation:
> https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
> It provides the following example: {"message": "%enc{%m}{JSON}"}
> 
>> I think performance shouldn't be your primary consideration, here.
> 
> I agree wholeheartedly with this sentiment, but we should remember
> that some users have a different set of constraints and requirements.
> 
> Carter Kozak
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: PatternLayout Vs JsonTemplateLayout/JsonLayout Performance Comparision

[Ralph Goers]

1. We need to mark JsonLayout as deprecated. We no longer recommend using it. 
Use JsonTemplateLayout instead.
2. The only consideration for JsonTemplateLayout is that you format the 
template correctly. 

FWIW, my employer has been using JsonTemplateLayout to log to ELK for quite a 
while now without any problems. Note that you can still use a pattern to format 
the message. This works very well. As you can see by the example below you can 
even include variables to add extra variables to be logged from the 
ThreadContextMap via overrides.

{
  "@timestamp": {
"$resolver": "timestamp",
"pattern": {
  "format": "-MM-dd'T'HH:mm:ss.SSS'Z'",
  "timeZone": "UTC"
}
  },
  "ecs.version": "1.11.0",
  "log.level": {
"$resolver": "level",
"field": "name"
  },
  "application": "\${lower:\${spring:spring.application.name}}",
  "short_message": {
"$resolver": "message",
"stringified": true
  },
  "message": {
"$resolver": "pattern",
"pattern": "[%t] %X{requestId, sessionId, loginId,  ipAddress, 
accountNumber, \${extraContextVars}} %C{1.}.%M:%L - %m%n"
  },
  "process.thread.name": {
"$resolver": "thread",
"field": "name"
  },
  "log.logger": {
"$resolver": "logger",
"field": "name"
  },
  "event.action": {
"$resolver": "marker",
"field": "name"
  },
  "event.data": {
"$resolver": "map",
"stringified": true
  },
  "labels": {
"$resolver": "mdc",
"flatten": true,
"stringified": true,
"pattern": "(?!(?i:token)).+"
  },
  "tags": {
"$resolver": "ndc"
  },
  "error.type": {
"$resolver": "exception",
"field": "className"
  },
  "error.message": {
"$resolver": "exception",
"field": "message"
  },
  "error.stack_trace": {
"$resolver": "exception",
"field": "stackTrace",
"stackTrace": {
  "stringified": true
}
  }
}


Ralph

> On Nov 16, 2022, at 3:54 AM, Ganapathi Vara Prasad 
>  wrote:
> 
> Hello Team,
> 
> Our log4j2 configuration uses *PatternLayout* and we are exploring
> switching to JsonLayout for simplifying integration with ELK. I am trying
> to find any performance comparison between pattern and json layouts but
> couldn't find any. I could find only the JsonTemplateLayout benchmark in
> the log4j-perf module.
> 
> I wanted to know:
> 
>   - Is it a reasonable thing to compare the performance of these two
>   layouts?
>   - Are there any existing resources comparing the performance of these
>   two layouts?
>   - What considerations should we make if we switch to JsonTemplateLayout?
> 
> Thank you for the help.
> 
> --Ganapati


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

[Ralph Goers]

There have only been 2 issues fixed since 2.19.0 was released 2 months ago.  I 
normally wouldn’t perform a release for so few non-critical changes after such 
a short period of time.

Ralph

> On Nov 10, 2022, at 1:10 AM, jeffrey.tho...@t-systems.com wrote:
> 
> Hallo Log4j Team,
> 
> any rough ETA on when a 2.19.1 release might take place?
> 
> On one of my tickets I was told by the developer that you are all very busy 
> working on 3.x so I should give a shout out here for a little 2.x love. 
> 
> Cheers, Jeff
> 


-
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

[Ralph Goers]

This indicates that for some reason Log4j 2 is now initializing earlier - 
before your system property is being set.

Your solution gets the currently configured LoggerContext (presumably using the 
default configuration) and causes it to reconfigure using the new location.

Ralph

> On Oct 17, 2022, at 6:03 AM, Joan ventusproxy 
>  wrote:
> 
> Hello,
> 
> Solved ... I don't exactly understand why ... but solved.
> 
> I had to change my code in this way. Instead of:
> System.setProperty("log4j.configurationFile", 
> "/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");
> this.systemLog = LogManager.getLogger("LOGGER_SYSTEM");
> 
> Now is:
> LoggerContext context = (LoggerContext) LogManager.getContext(false);
> context.setConfigLocation("/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");
> 
> this.systemLog = context.getLogger("LOGGER_SYSTEM");
> 
> 
> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Joan ventusproxy  
> Sent: Monday, October 17, 2022 1:47 PM
> To: 'Log4J Users List' 
> Subject: RE: Issue after moving to log4j 2.19
> 
> Hello,
> 
> Investigating a little more ...
> 
> If I set the variable 
> -Dlog4j.configurationFile=/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml 
> on the tomcat startup script, it works.
> 
> But setting this on my application, as we always did, it does not work any 
> more:
> System.setProperty("log4j.configurationFile", 
> "/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");
> 
> The point is this is a simplified example, building this path is much more 
> complicated and it must be done at application level, not tomcat level.
> 
> By the way, our web.xml contains this:
> 
>  
>isLog4jContextSelectorNamed
>true
>  
> 
>  
>log4jContextName
>ventusproxy
>  
> 
> Thanks,
> 
> Joan.
> 
> 
> -Original Message-
> From: Joan ventusproxy  
> Sent: Sunday, October 16, 2022 9:03 PM
> To: 'Log4J Users List' 
> Subject: RE: Issue after moving to log4j 2.19
> 
> Is not this? (second gist):
> 
> DEBUG StatusLogger Watching configuration 
> '/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml' for lastModified Sat Oct 
> 15 21:55:38 UTC 2022 (1665870938000) DEBUG StatusLogger Apache Log4j Core 
> 2.19.0 initializing configuration 
> XmlConfiguration[location=/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml]
> 
> Joan.
> 
> -Original Message-
> From: Ralph Goers 
> Sent: Sunday, October 16, 2022 2:44 AM
> To: Log4J Users List 
> Subject: Re: Issue after moving to log4j 2.19
> 
> In both of those log files Log4j is not seeing any value as being set of 
> log4j.configurationFile. It is ending up using the default configuration.
> 
> Ralph
> 
>> On Oct 15, 2022, at 3:45 PM, Joan ventusproxy 
>>  wrote:
>> 
>> Hi Piotr,
>> 
>> Thanks for your quick response.
>> 
>> Below two gists with the traces for both cases:
>> 
>> 1. Using "this.systemLog = LogManager.getLogger("LOGGER_SYSTEM");":
>> https://gist.githubusercontent.com/joanbalaguero/a59fb664774c44535c108
>> 17900a80ed5/raw/8bb6b6a963a607f0d99105248ce32a28ad39590a/gistfile1.txt
>> 
>> In this case logs are not created.
>> 
>> 
>> 2. Using "this.systemLog = 
>> LogManager.getContext().getLogger("LOGGER_SYSTEM");":
>> https://gist.githubusercontent.com/joanbalaguero/acd0a4edaf856ad34c44a
>> 196caef7bdc/raw/474febc0397b97a9b941dbd86b830149ac94ad07/gistfile1.txt
>> 
>> In this case logs are created and content is logged into them correctly, but 
>> the hazelcast log (from "com.hazelcast") is not sent to the SYSTEM_LOG. 
>> 
>> 
>> The " log4j.configurationFile " variable is set in this way:
>> System.setProperty("log4j.configurationFile", 
>> "/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");
>> 
>> And tomcat starts with:
>> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLogger
>> ContextSelector
>> 
>> 
>> The point is that for years we have been running this without issues using 
>> point 1, without getting the context from the LogManager.
>> 
>> One more clue. As I said, this is not working fine on our new installation 
>> with Centos9 Stream, Apache Tomcat 8.5.83 and Zing JVM 11. Exactly the same 
>> code running locally on a windows 10 with Apache Tomcat 8.5.39 and Oracle 
>> jdk 11 works perfectly, logs are created and the hazelcast logging is sent 
>> to the SYSTEM_LOG.
>> 
>> 
>> Thanks

Re: Issue after moving to log4j 2.19

[Ralph Goers]

In both of those log files Log4j is not seeing any value as being set of 
log4j.configurationFile. It is ending up using the default configuration.

Ralph

> On Oct 15, 2022, at 3:45 PM, Joan ventusproxy 
>  wrote:
> 
> Hi Piotr,
> 
> Thanks for your quick response.
> 
> Below two gists with the traces for both cases:
> 
> 1. Using "this.systemLog = LogManager.getLogger("LOGGER_SYSTEM");":
> https://gist.githubusercontent.com/joanbalaguero/a59fb664774c44535c10817900a80ed5/raw/8bb6b6a963a607f0d99105248ce32a28ad39590a/gistfile1.txt
> 
> In this case logs are not created.
> 
> 
> 2. Using "this.systemLog = 
> LogManager.getContext().getLogger("LOGGER_SYSTEM");":
> https://gist.githubusercontent.com/joanbalaguero/acd0a4edaf856ad34c44a196caef7bdc/raw/474febc0397b97a9b941dbd86b830149ac94ad07/gistfile1.txt
> 
> In this case logs are created and content is logged into them correctly, but 
> the hazelcast log (from "com.hazelcast") is not sent to the SYSTEM_LOG. 
> 
> 
> The " log4j.configurationFile " variable is set in this way:
> System.setProperty("log4j.configurationFile", 
> "/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");
> 
> And tomcat starts with:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> 
> 
> The point is that for years we have been running this without issues using 
> point 1, without getting the context from the LogManager.
> 
> One more clue. As I said, this is not working fine on our new installation 
> with Centos9 Stream, Apache Tomcat 8.5.83 and Zing JVM 11. Exactly the same 
> code running locally on a windows 10 with Apache Tomcat 8.5.39 and Oracle jdk 
> 11 works perfectly, logs are created and the hazelcast logging is sent to the 
> SYSTEM_LOG.
> 
> 
> Thanks,
> 
> Joan.
> 
> -Original Message-
> From: Piotr P. Karwasz  
> Sent: Friday, October 14, 2022 5:23 PM
> To: Log4J Users List 
> Subject: Re: Issue after moving to log4j 2.19
> 
> 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
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

[Ralph Goers]

> On Oct 14, 2022, at 8:53 AM, Piotr P. Karwasz  wrote:
> 
> 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.

I think Piotr’s statement should be qualified. Currently, many modules are 
fully 
compliant JPMS modules in master. However there are still many that are not. 
It isn’t clear to me how many of the others are really worth the effort of 
doing 
(and it is a large amount of effort).

As for a timeframe. Here are the items still left on the list:
1. Finish modularizing any remaining Maven modules that make sense to do.
2. If at all possible, implement 
https://cwiki.apache.org/confluence/display/LOGGING/Properties+Enhancement
3. Ensure fixes included in release-2.x have not been lost in master.

While item 1 is straightforward, it is still a bit of busy work. Items 2 and 3 
however 
are quite a bit of work. To be honest, I would have liked for 3.0.0-alpha1 to 
have 
been released months ago but there aren’t enough hours in the day. So if you 
can 
provide help by providing PRs for any of these it would be appreciated.


Ralph
-
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.19.0 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.19.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html.

This release primarily contains bug fixes and minor enhancements.

Due to breaks in compatibility in the SLF4J binding, Log4j now ships with two 
versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with 
SLF4J 1.7.x and earlier and log4j-slf4j2-impl should be used with SLF4J 2.x and 
later. SLF4J-1.8.x is no longer supported as a GA release never occurred.

The Log4j 2.19.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.19.0

Changes in this version include:

New Features
• LOG4J2-3583: Add support for SLF4J2 stack-valued MDC. Thanks to 
Pierrick Terrettaz.
• LOG4J2-2975: Add implementation of SLF4J2 fluent API. Thanks to 
Daniel Gray.

Fixed Bugs
• LOG4J2-3578: Generate new SSL certs for testing.
• LOG4J2-3556: Make JsonTemplateLayout stack trace truncation operate 
for each label block. Thanks to Arthur Gavlyukovskiy.
• LOG4J2-3550: SystemPropertyArbiter was assigning the value as the 
name. Thanks to DongjianPeng.
• LOG4J2-3560: Logger$PrivateConfig.filter(Level, Marker, String) was 
allocating empty varargs array. Thanks to David Schlosnagle.
• LOG4J2-3561: Allows a space separated list of style specifiers in the 
%style pattern for consistency with %highlight. Thanks to Robert Papp.
• LOG4J2-3564: Fix NPE in log4j-to-jul in the case the root logger 
level is null.
• LOG4J2-3545: Add correct manifest entries for OSGi to log4j-jcl 
Thanks to Johan Compagner.
• LOG4J2-3565: Fix RollingRandomAccessFileAppender with 
DirectWriteRolloverStrategy can't create the first log file of different 
directory.
• LOG4J2-3579: Fix ServiceLoaderUtil behavior in the presence of a 
SecurityManager. Thanks to Boris Unckel.
• LOG4J2-3559: Fix resolution of properties not starting with log4j2.. 
Thanks to Gary Gregory.
• LOG4J2-3557: Fix recursion between Log4j 1.2 LogManager and Category. 
Thanks to Andreas Leitgeb.
• LOG4J2-3587: Fix regression in Rfc5424Layout default values. Thanks 
to Tomas Micko.
• LOG4J2-3548: Improve support for passwordless keystores. Thanks to 
Kristof Farkas-Pall.
• LOG4J2-708: Add async support to Log4jServletFilter.

Changes
• LOG4J2-3572: Add getExplicitLevel method to LoggerConfig.
• LOG4J2-3589: Allow Plugins to be injected with the LoggerContext 
reference.
• LOG4J2-3588: Allow PropertySources to be added.

Removed
• LOG4J2-3573: Removed build page in favor of a single build 
instructions file. Thanks to Wolff Bock von Wuelfingen.
• LOG4J2-3590: Remove SLF4J 1.8.x binding.

Apache Log4j 2.19.0 requires a minimum of Java 8 to build and run. Log4j 2.12.4 
is the last release to support Java 7. Log4j 2.3.2 is the last release to 
support Java 6. Java 6 and Java 7 are no longer supported by the Log4j team.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Apache Log4j 2 website:

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

Re: log4j2 and WebSphere

[Ralph Goers]

You are in the correct place. You might also search StackOverflow if you 
haven’t already.

We would need some more information on how things are configured and what you 
have tried. 

I don’t believe any of the committers use WebSphere but we have had other 
questions recently.

But identifying how to get it to work requires first knowing how you want it to 
behave.

Ralph

> On Sep 9, 2022, at 7:57 AM, Parrott, Kevin  wrote:
> 
> I am new to this user list so my apologies if I am not sending my question 
> properly…
>  
> At any rate,   we recently tried to migrate our java application (EARs) 
> running in WebSphere on a Linux system to
> log4j2.   Previously we were using an older log4j 1.X version.However,  
> once we converted to the new log4j2,
> we are having issues with it picking up our configuration and/or jars.
>  
> Does anyone have any tips on getting log4j2 to work with WebSphere in Linux 
> or can you point me to someplace
> that can help resolve our issues?
>  
> NEED HELP WITH IAG TECHNOLOGY? PLEASE LOG A SELF-SERVICE TICKET HERE 
> 
>  
> 
> Kevin Parrott
> Store Systems,
> Sr Development Engineer
> O: 215.430.9095 x6159
> kevin_parr...@pepboys.com   
> 3111 West Allegheny Avenue
> Philadelphia, PA 19132
> PepBoys.com 
>  
>  
> Upcoming Out of Office Dates:none
>  
> Pep Boys Email Disclaimer: It is the policy of The Pep Boys – Manny, Moe & 
> Jack LLC and its affiliates not to enter into contracts or binding 
> commitments by email. Nothing in this email shall constitute a contract or 
> legally binding commitment by The Pep Boys – Manny, Moe & Jack LLC and its 
> affiliates. This email is intended only for the person or entity to which it 
> is addressed and may contain confidential, proprietary and/or privileged 
> material. Any review, distribution, reliance on, or other use of this 
> information by persons or entities other than the intended recipient is 
> prohibited. If you receive this message in error, please immediately notify 
> the sender and delete it and all copies of it from your system. Thank You.

Re: Converting custom Appender to Log4j v2

[Ralph Goers]

Have you tried running under the debugger with a breakpoint at setFile()?
That should show you the call stack and whether you really got there 
through that main. If it was then that main would show up in the list of 
processes that are running, although you might not be able to tell how it 
was invoked.

You should also be able to disassemble SandcastleService. I know Ihtellij 
does that automatically and I expect other IDEs do as well.

Ralph

> On Sep 9, 2022, at 7:49 AM, Joel Griffith  wrote:
> 
> I've followed my application's usage of the `setFile()` command up the
> chain of invocations to try to figure out what it's doing so that I can
> implement something different for Log4j v2.
> 
> Ultimately, the function is invoked by the `main()` method of a file
> `SandcastleService.jar`, where it is used to change the FileAppender output
> file of the Root Logger.  I don't know enough about Java to investigate
> further, and I need help.
> 
> It is obvious from the structure and nature of the library I'm working on
> that no one was ever expected to type `$ java SandcastleService` at the
> command line to invoke this, which is the only use of the `main()` method I
> know about.
> 
> When the library is built, it is part of a JAR file `beaches.jar`.  That
> JAR file has a manifest that includes a field `Main-Class:
> org.file.path.tides.scheduler`.  So, `SandcastleService.main()` is not used
> for that purpose.
> 
> Does anyone have any ideas for how I can figure out what
> `SandcastleService.main()` is doing with the Log4j v1 `setFile()` method?
> The string "SandcastleService.main(" doesn't appear anywhere else in the
> code base, so it's not directly invoked anywhere.
> 
> Joel
> 
> 
> On Fri, Aug 26, 2022 at 6:21 PM Ralph Goers 
> wrote:
> 
>> 
>> 
>>> On Aug 26, 2022, at 1:45 PM, Joel Griffith  wrote:
>>> 
>>> 
>>> Its purpose is to change the output file of the Root Logger's
>> FileAppender
>>> (we assume it has only one), or to add a new FileAppender to the Root
>>> Logger if one does not already exist.  I can eliminate this use of
>>> FileAppender.setFile() by rewriting the entire function for Log4j v2.
>> How
>>> changing a FileAppender's output file done in v2?  I cannot find any hint
>>> online.  I read some about Lookups, which someone mentioned, but the only
>>> page I found was all configuration, no code.
>>> 
>> 
>> The only way to change the output destination would be to create a new
>> Appender with the new target file and replace the current appender with it.
>> The file attribute of a FileAppender in Log4j 2 is immutable. In the
>> RollingFileAppender
>> you cannot change the name of the target file but the file being written
>> to is
>> moved and a new file with the same name is created when a rollover occurs.
>> 
>> In order to have  the ability to change the file at any time locking would
>> be
>> required and Log4j 2 minimizes locking wherever it can.
>> 
>> But rather than just copying code and trying to figure out how to emulate
>> it
>> with Log4j 2 it would be better to figure out what the requirement is that
>> is
>> driving the need to change the file name and then ask how that requirement
>> can be met.
>> 
>> Ralph
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>> 


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

Re: Converting custom Appender to Log4j v2

[Ralph Goers]

> On Aug 26, 2022, at 1:45 PM, Joel Griffith  wrote:
> 
> 
> Its purpose is to change the output file of the Root Logger's FileAppender
> (we assume it has only one), or to add a new FileAppender to the Root
> Logger if one does not already exist.  I can eliminate this use of
> FileAppender.setFile() by rewriting the entire function for Log4j v2.  How
> changing a FileAppender's output file done in v2?  I cannot find any hint
> online.  I read some about Lookups, which someone mentioned, but the only
> page I found was all configuration, no code.
> 

The only way to change the output destination would be to create a new 
Appender with the new target file and replace the current appender with it.
The file attribute of a FileAppender in Log4j 2 is immutable. In the 
RollingFileAppender 
you cannot change the name of the target file but the file being written to is 
moved and a new file with the same name is created when a rollover occurs.

In order to have  the ability to change the file at any time locking would be 
required and Log4j 2 minimizes locking wherever it can.

But rather than just copying code and trying to figure out how to emulate it 
with Log4j 2 it would be better to figure out what the requirement is that is 
driving the need to change the file name and then ask how that requirement 
can be met.

Ralph



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

Re: Converting custom Appender to Log4j v2

[Ralph Goers]

In Log4j 1.2 a Category was the base class for a Logger. So this would simply 
be 
looking for all the Appenders attached to the Logger. If a Category/Logger has 
no 
Appenders then it searches the parent hierarchy until it finds one. Note that 
even 
if it finds one if the Logger is configured as additive (the default) then the 
event will 
also be passed to the Logger’s parents. 

I haven’t looked at the code recently but I’d bet getAllAppenders only returns 
the 
Appenders directly attached to the Logger/Category.

Ralph

> On Aug 23, 2022, at 1:15 PM, Joel Griffith  wrote:
> 
> I'm still trying to parse some Log4j v1 code for the update, and I hit
> something I can't find.
> 
> The docs here:
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#getAllAppenders()
> say that the Logger.getAllAppenders() method "Get[s] the appenders
> contained in this category as an Enumeration."  There is no definition of
> what it means for an appender to be "contained in" a category, however, so
> I'm unable to predict exactly what the method will return.
> 
> As precisely as possible, what defines the set of appenders that are
> "contained in" a category like a logger?  In particular, does a child
> logger contain appenders assigned to its parent?  Does a parent logger
> contain appenders assigned to its child?
> 
> Thanks,
> Joel
> 
> 
> 
> 
> 
> On Tue, Aug 16, 2022 at 3:37 AM Markus Dimmerling 
> wrote:
> 
>>> As for delaying creating the file, that can be accomplished just by
>> specifying createOnDemand=“true”.
>> Keep in mind, that this is not true for parent folders. Parent folders
>> will be created on initialization even before createOnDemand. (At least for
>> RollingFileAppenders)
>> 
>> This was my workaround for that issue: A RoutingAppender wrapping the
>> RollingFileAppender and routing all logging to null until the value is not
>> empty anymore.
>> 
>> 
>>  
>>
>>  
>>
>>
>>  >   fileName="${ctx: parent.folder}/Logging.log"
>>   filePattern="${ctx: parent.folder}/Logging.log.%i"
>>   createOnDemand="true">
>>...
>>  
>>
>>  
>> 
>> 


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

Re: Converting custom Appender to Log4j v2

[Ralph Goers]

This code appears to doing two things:
1. Provide a custom setFile method to set the file name, buffer size, 
and the append and bufferedIO flags. It also always sets immediateFlush 
to false.
2. Only opens the file when fileNameConfigured is called.

Other than that it is just the standard FileAppender.

Given that, there really is no need for this in Log4j2.

I haven’t seen the code that calls setFile but you can use custom 
Lookups if required to provide the values for the file name, buffer 
size and flags. To be honest though, I’d be surprised if custom 
Lookups are really required. I’d guess you can probably accomplish 
what you need with the standard lookups.

As for delaying creating the file, that can be accomplished just by 
specifying createOnDemand=“true”.

Ralph

.

> On Aug 15, 2022, at 10:09 AM, Joel Griffith  wrote:
> 
> I guess I can.  90 lines isn't too big for an email, is it?
> 
> * start code *
> 
> import java.io.BufferedWriter;
> import java.io.File;
> import java.io.FileNotFoundException;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.Writer;
> 
> import org.apache.logging.log4j.core.appender.FileAppender;
> import org.apache.logging.log4j.status.StatusLogger;
> 
> public class LazyFileAppender extends FileAppender {
>/**
> * Override FileAppender.setFile to avoid creating an empty log file
> before
> * the code has a chance to customize the file name.
> */
>public synchronized void setFile(String fileName, boolean append,
> boolean bufferedIO, int bufferSize)
>throws IOException {
>StatusLogger.debug("setFile called: {}, {}", fileName, append);
> 
>if (this.qw != null) {
>return;
>}
> 
>// set a stdout writer just in case
>reset();
>Writer fw = createWriter(System.out);
>this.setQWForFiles(fw);
> 
>this.fileName = fileName;
>this.fileAppend = append;
>this.bufferedIO = bufferedIO;
>this.bufferSize = bufferSize;
>StatusLogger.debug("setFile ended");
>}
> 
>/**
> * Calling this method will signal this class that the log file name
> * has been configured and that the file can now be opened.
> * @throws IOException
> */
>public void fileNameConfigured() throws IOException {
>StatusLogger.debug("fileNameConfigured called");
> 
>// It does not make sense to have immediate flush and bufferedIO.
>if (this.bufferedIO) {
>setImmediateFlush(false);
>}
> 
>// Save file name since reset() sets it to null
>String fileName = this.fileName;
> 
>// Set to null to prevent parent class from closing System.out
>this.qw = null;
>reset();
>this.fileName = fileName;
>FileOutputStream ostream = null;
>try {
>//
>// attempt to create file
>//
>ostream = new FileOutputStream(this.fileName, this.fileAppend);
>}
>catch (FileNotFoundException ex) {
>//
>// if parent directory does not exist then
>// attempt to create it and try to create file
>// see bug 9150
>//
>String parentName = new File(this.fileName).getParent();
>if (parentName != null) {
>File parentDir = new File(parentName);
>if (!parentDir.exists() && parentDir.mkdirs()) {
>ostream = new FileOutputStream(this.fileName,
> this.fileAppend);
>}
>else {
>throw ex;
>}
>}
>else {
>throw ex;
>}
>}
>Writer fw = createWriter(ostream);
>if (this.bufferedIO) {
>fw = new BufferedWriter(fw, this.bufferSize);
>}
>this.setQWForFiles(fw);
>writeHeader();
>StatusLogger.debug("fileNameConfigured ended");
>}
> }
> 
> * end code *
> 
> Joel
> 
> On Mon, Aug 15, 2022 at 11:33 AM Ralph Goers 
> wrote:
> 
>> This is a problem. Log4j supports Lookups, which usually eliminate the
>> need
>> to override things like setFile since you can create a custom lookup to do
>> whatever needs to be done.
>> 
>> Is there any chance you can post the code so we can figure out what it
>> does?
>> 
>> Ralph
>> 
>>> On Aug 15, 2022, at 8:21 AM, Joel Griffith  wrote:
>>> 
>>> I don't know what the old appender does, in part becaus

Re: Converting custom Appender to Log4j v2

[Ralph Goers]

This is a problem. Log4j supports Lookups, which usually eliminate the need 
to override things like setFile since you can create a custom lookup to do 
whatever needs to be done.

Is there any chance you can post the code so we can figure out what it does?

Ralph

> On Aug 15, 2022, at 8:21 AM, Joel Griffith  wrote:
> 
> I don't know what the old appender does, in part because I'm not a good
> enough programmer to interpret it, and in part because the bulk of what it
> does is contained in the source code of the classes that it subclasses, and
> I don't have that v1 source code.
> 
> One thing I've figured out that it does is override the v1 FileAppender's
> setFile() method.  I've also figured out that the v2 FileAppender doesn't
> have that method.  So... I don't know what to do about that.
> 
> Joel
> 
> On Fri, Aug 12, 2022 at 7:18 PM Gary Gregory  wrote:
> 
>> Joel,
>> 
>> Is it possible to use Log4j 2's much richer feature set as is? Perhaps you
>> could explain what is it your old appender does that requires custom code.
>> 
>> Gary
>> 
>> On Fri, Aug 12, 2022, 15:35 Joel Griffith  wrote:
>> 
>>> I have a Java application containing a package written to use Log4j v1.
>> I
>>> am struggling to update this package to use Log4j v2 to remediate its
>>> security vulnerabilities.
>>> 
>>> The package contains a custom Appender that subclasses Log4j v1's
>>> FileAppender.  I am stumped at how to convert this file to Log4j v2.  In
>>> Log4j v2, the FileAppender class is 'final' and cannot be subclassed, so
>> I
>>> cannot create a new version of the custom Appender that mirrors the
>> first.
>>> More importantly, perhaps, is that the Log4j v2 FileAppender is a Plugin
>>> and completely different in structure from the Log4j v1 FileAppender.
>>> 
>>> I found this page that ostensibly explains how to extend Log4j:
>>> https://logging.apache.org/log4j/2.x/manual/extending.html#Appenders
>>> but it contains no information about actually extending Appenders or
>>> procedures for accomplishing an equivalent goal.
>>> 
>>> Is there any reasonable way of converting this custom Appender from Log4j
>>> v1 to v2?
>>> 
>>> Thanks,
>>> Joel
>>> 
>> 


-
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

[Ralph Goers]

The recommended approach is to do what Spring Boot does - build 
a jar that has all its dependent jars in a directory. A jar is just a zip file 
so you can either unzip it before running or have the start up program 
set the classpath to the directory inside the zip. Of course, that may 
mean you need a custom ClassLoader but I’d be willing to bet you can 
find something that already does this. Or build it as a Spring Boot app.

Ralph

> On Jul 7, 2022, at 4:06 AM, Alain Désilets  wrote:
> 
> On Thu, Jul 7, 2022 at 6:14 AM Piotr P. Karwasz 
> wrote:
> 
>> 
>> 
>> 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.
>> 
> 
> Thx Piotr,
> 
> This is interesting. The reason why I added this filter is that I was
> getting a
> 
> log4j2 ERROR StatusLogger Unrecognized conversion specifier
> 
> Reading about this, I found several posts that said the solution was to
> filter the Log4j2Plugins.dat files.
> 
> So I should merge the files instead?
> 
> Question: Would I get the same issue if instead of creating an Uber jar, I
> created a jar with just my project's classes, and then ran it with
> 
> -cp log4j2-compatibility-1.0.0.jar:/path/to/the/depencies/*.jar


-
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

[Ralph Goers]

When you run as an uber jar you are most likely breaking things. 

Log4j uses a file named Log4j2Plugins.dat to define its plugins. Every jar that 
has Log4j plugins will have one. When you create an uber jar most likely only 
one is left and it probably doesn’t contain the core Log4j stuff.

To solve this you need to use 
https://github.com/edwgiz/maven-shaded-log4j-transformer.

Ralph

> On Jul 6, 2022, at 5:07 AM, Alain Désilets  wrote:
> 
> Here is another interesting thing.
> 
> If I remove the log4j-1.2-api dependency from the pom, then the when I try
> to build the project from Terminal, I get the following failure:
> 
> [*ERROR*] 
> */Users/desilets/Documents/GitRepositories/SpikeLog4j2Compatibility/src/main/java/org/examples/HelloWorld.java:[3,24]
> package org.apache.log4j does not exist*
> 
> 
> Which is what I would expect.
> 
> But the project builds and runs without problem in intelliJ. This is true
> even if I do "Invalidate caches and Restart".
> 
> Very strange.
> 
> On Wed, Jul 6, 2022 at 7:27 AM Alain Désilets 
> wrote:
> 
>> I am trying to use log4j2 through log4j-1.2-api in the context of an
>> uber-jar created with the maven shade plugin and am experiencing issues.
>> 
>> I wrote a simple HelloWorld class that illustrates the issue.
>> 
>> When I run this class through intelliJ, everything works fine. But when I
>> run it through a terminal, I get
>> 
>> ERROR StatusLogger Reconfiguration failed: No configuration found for
>> '55f96302' at 'null' in 'null'
>> 
>> 
>> In both cases, I invoke the command with
>> 
>> -Dlog4j.configuration=/path/to/my/log4j.properties
>> 
>> 
>> And the log4j.properties is in the old log4j style (i.e. NOT log4j2 style).
>> 
>> Not sure what I am doing wrong.
>> 
>> One thing I notice is that the class path is different in both situations.
>> When running through intelliJ, it contains a great number of jars,
>> including:
>> 
>> 
>>   -
>>   
>> .m2/repository/org/apache/logging/log4j/log4j-core/2.17.2/log4j-core-2.17.2.jar
>>   -
>>   
>> .m2/repository/org/apache/logging/log4j/log4j-api/2.17.2/log4j-api-2.17.2.jar
>>   -
>>   
>> .m2/repository/org/apache/logging/log4j/log4j-1.2-api/2.17.2/log4j-1.2-api-2.17.2.jar
>> 
>> whereas when I run it from terminal, it just contains my one uber-jar. But
>> based on the content of my pom, I expect that the uber jar will contain
>> classes from those same log4j jars.
>> 
>> Here are the details of this HelloWorld example.
>> 
>> 
>> This is the HelloWorld class
>> 
>> package org.examples;
>> 
>> import org.apache.log4j.Logger;
>> 
>> import java.net.URL;
>> import java.net.URLClassLoader;
>> 
>> public class HelloWorld {
>> 
>>  public static void main(String[] args) {
>>printClassPath();
>>Logger logger = Logger.getLogger("org.examples.HelloWorld");
>>logger.trace("Hello from Logger");
>>  }
>> 
>>  private static void printClassPath() {
>>ClassLoader cl = ClassLoader.getSystemClassLoader();
>>URL[] urls = ((URLClassLoader)cl).getURLs();
>> 
>>System.out.println("Class path is:");
>>for(URL url: urls){
>>  System.out.println(url.getFile());
>>}
>>  }
>> }
>> 
>> 
>> And here is the pom:
>> 
>> http://maven.apache.org/POM/4.0.0; 
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>> 
>>  4.0.0
>>  org.examples
>>  log4j2-compatibility
>>  1.0.0
>> 
>>  
>>2.17.2
>>  
>> 
>>  
>>
>>  
>>  
>>org.apache.maven.plugins
>>maven-shade-plugin
>>3.1.0
>>
>>  true
>>  jar-with-dependencies
>>  
>>
>>  *:*
>>  
>>
>>**/Log4j2Plugins.dat
>>  
>>
>>  
>>
>>
>>  
>>package
>>
>>  shade
>>
>>  
>>
>>  
>>
>>  
>> 
>>  
>> 
>>
>>  org.apache.logging.log4j
>>  log4j-core
>>  ${log4j.version}
>>
>> 
>>
>>  org.apache.logging.log4j
>>  log4j-1.2-api
>>  ${log4j.version}
>>
>> 
>>  
>> 
>> 
>> 
>> And here is the log4.properties file
>> 
>> # Log to stdout only
>> log4j.rootLogger=warn, stdout
>> 
>> # Configure the stdout logger
>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
>> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
>> log4j.appender.stdout.layout.ConversionPattern =-- %c{2}: %m%n
>> 
>> # Activate some traces
>> log4j.logger.org.examples.HelloWorld=trace
>> 
>> 


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

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.18.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html.

This release primarily contains bug fixes and minor enhancements.

Due to a break in compatibility in the SLF4J binding, Log4j now ships with two 
versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with 
SLF4J 1.7.x and earlier and log4j-slf4j18-impl should be used with SLF4J 1.8.x 
and later. SLF4J-2.0.0 alpha releases are not fully supported. See 
https://issues.apache.org/jira/browse/LOG4J2-2975 and 
https://jira.qos.ch/browse/SLF4J-511.

The Log4j 2.18.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.18.0

Changes in this version include:

New Features

• LOG4J2-3495: Add MutableThreadContextMapFilter.
• LOG4J2-3472: Add support for custom LMAX disruptor WaitStrategy 
configuration.
• LOG4J2-3419: Add support for custom Log4j 1.x levels.
• LOG4J2-3440: Add support for adding and retrieving appenders in Log4j 
1.x bridge.
• LOG4J2-3362: Add support for Jakarta Mail API in the SMTP appender.
• LOG4J2-3483: Add support for Apache Extras' RollingFileAppender in 
Log4j 1.x bridge.
• LOG4J2-3538: Add support for 24 colors in highlighting Thanks to 
Pavel_K.
Fixed Bugs

• LOG4J2-3339: DirectWriteRolloverStrategy should use the current time 
when creating files.
• LOG4J2-3534: Fix LevelRangeFilterBuilder to align with log4j1's 
behavior.
• LOG4J2-3527: Don't use Paths.get() to avoid circular file systems.
• LOG4J2-3490: The DirectWriteRolloverStrategy was not detecting the 
correct index to use during startup.
• LOG4J2-3432: SizeBasedTriggeringPolicy would fail to rename files 
properly when integer pattern contained a leading zero.
• LOG4J2-3491: Async Loggers were including the location information by 
default. Thanks to Avihai Marchiano.
• LOG4J2-1376: Allow enterprise id to be an OID fragment.
• LOG4J2-3493: ClassArbiter's newBuilder method referenced the wrong 
class. Thanks to Dmytro Voloshyn.
• LOG4J2-3481: HttpWatcher did not pass credentials when polling.
• LOG4J2-3482: UrlConnectionFactory.createConnection now accepts an 
AuthorizationProvider as a parameter.
• LOG4J2-3477: Add the missing context stack to JsonLayout template. 
Thanks to filipc.
• LOG4J2-3393: Improve JsonTemplateLayout performance.
• LOG4J2-3424: Properties defined in configuration using a value 
attribute (as opposed to element) are read correctly.
• LOG4J2-3413: Fix resolution of non-Log4j properties.
• LOG4J2-3423: JAR file containing Log4j configuration isn't closed. 
Thanks to Radim Tlusty.
• LOG4J2-3425: Syslog appender lacks the SocketOptions setting. Thanks 
to Jiří Smolík.
• : Improve validation and reporting of configuration errors.
• : Log4j 1.2 bridge should generate Log4j 2.x messages based on the 
parameter runtime type.
• LOG4J2-3426: Log4j 1.2 bridge should not wrap components 
unnecessarily. Thanks to Pooja Pandey.
• LOG4J2-3418: Fixes Spring Boot logging system registration in a 
multi-application environment.
• LOG4J2-3040: Avoid ClassCastException in JeroMqManager with custom 
LoggerContextFactory #791. Thanks to LF-Lin.
• : Fix minor typo #792. Thanks to LF-Lin.
• LOG4J2-3439: Fixes default SslConfiguration, when a custom keystore 
is used. Thanks to Jayesh Netravali.
• LOG4J2-3447: Fixes appender concurrency problems in Log4j 1.x bridge. 
Thanks to Pooja Pandey.
• LOG4J2-3452: Fix and test for race condition in FileUtils.mkdir(). 
Thanks to Stefan Vodita.
• LOG4J2-3458: LocalizedMessage logs misleading errors on the console.
• LOG4J2-3359: Fixes the syslog appender in Log4j 1.x bridge, when used 
with a custom layout. Thanks to Tukesh.
• LOG4J2-3359: log4j-1.2-api 2.17.2 throws NullPointerException while 
removing appender with name as null. Thanks to Rajesh.
• LOG4J2-2872: Fix problem with non-uppercase custom levels. Thanks to 
Alla Gofman.
• LOG4J2-3475: Add missing message parameterization in RegexFilter. 
Thanks to Jeremy Lin.
• LOG4J2-3428: Update 3rd party dependencies for 2.18.0.
• 

Re: Need help creating second, separate logger

[Ralph Goers]

Yes, I’d like to know that too. We have consistently found in the past that 
questions 
regarding “how can I make this code work?” almost always do not produce as good 
results as when answering “how can I make this use case work?”.

Ralph

> On May 20, 2022, at 6:16 AM, Volkan Yazıcı  wrote:
> 
> Stephen, given your past questions, I see that you are trying to
> programmatically configure Log4j with interesting features, e.g., multiple
> logger contexts and such. May I ask what is your use case? What are you
> exactly trying to solve?
> 
> On Thu, May 19, 2022 at 5:57 PM Stephen Johns 
> wrote:
> 
>> I am trying to create a completely separate second
>> Context/Configuration/Logger - not a logger within an existing
>> config/context.
>> Log messages are going to STDOUT.
>> 
>> 
>> Current code
>> 
>>ConfigurationBuilder _configurationBuilder =
>> ConfigurationBuilderFactory.newConfigurationBuilder();
>>_configurationBuilder.setConfigurationName("SMDR_DEBUG_" + pName);
>>LoggerContext _loggerContext = new LoggerContext("SMDR_DEBUG_" +
>> pName);
>>_configurationBuilder.setLoggerContext(_loggerContext);
>>_configurationBuilder.setStatusLevel(Level.TRACE);
>> 
>> 
>>// Create the appender
>>AppenderComponentBuilder log4jFileAppenderBuilder =
>> _configurationBuilder.
>>newAppender(pName + "_SmdrDailyRollingFileAppender",
>> "RollingFile");
>>log4jFileAppenderBuilder.addAttribute("filename", pLogFilename);
>>log4jFileAppenderBuilder.addAttribute("filePattern",
>> pLogFilenamePattern);
>> 
>>// Setup roll-over
>>ComponentBuilder triggeringPolicy =
>> _configurationBuilder.newComponent("Policies")
>> 
>> 
>> .addComponent(_configurationBuilder.newComponent("TimeBasedTriggeringPolicy").
>>addAttribute("interval", "1"));
>>log4jFileAppenderBuilder.addComponent(triggeringPolicy);
>> 
>>// Configure the PatternLayout
>>LayoutComponentBuilder layoutComponentBuilder =
>> _configurationBuilder.newLayout("PatternLayout").
>>addAttribute("pattern", DEBUG_PATTERN_LAYOUT_STRING);
>>log4jFileAppenderBuilder.add(layoutComponentBuilder);
>> 
>>// Add it back into configuration
>>_configurationBuilder.add(log4jFileAppenderBuilder);
>> 
>>// https://logging.apache.org/log4j/2.x/manual/customconfig.html
>>RootLoggerComponentBuilder loggerBuilder =
>> _configurationBuilder.newRootLogger(Level.DEBUG);
>>loggerBuilder.add(_configurationBuilder.newAppenderRef(pName +
>> "_SmdrDailyRollingFileAppender"));
>>loggerBuilder.addAttribute("additivity", false);
>>_configurationBuilder.add(loggerBuilder);
>> 
>>LoggerContext _lc =
>> Configurator.initialize(_configurationBuilder.build());
>> 
>>System.out.println("* SRJ SRJ SMDR context from initialize is "
>> + _lc);
>> 
>>Logger _g = _loggerContext.getRootLogger();
>>System.out.println("* SRJ SRJ SMDR rootlogger from context is "
>> + _g);
>>_g.error("* SRJ SRJ ROOT LOGGER IN SMDR_DEBUG.txt");
>> 
>>Logger _gg = _loggerContext.getLogger(pName);
>>System.out.println("* SRJ SRJ SMDR logger "+pName+" from
>> context is " + _gg);
>>_gg.error("* SRJ SRJ "+pName+" LOGGER IN SMDR_DEBUG.txt");
>> 
>> The .error() calls above go to STDOUT.  Note that I have tried using
>> reconfigure instead of initialize, but that messes up my original
>> configuration.
>> 
>> The loggers seem wrong, as I print them out and they seem like they are
>> right name, but at error level
>> * SRJ SRJ SMDR rootlogger from context is :ERROR in SMDR_DEBUG_Global
>> 16:23:59.989 [main] ERROR  - * SRJ SRJ ROOT LOGGER IN SMDR_DEBUG.txt
>> <-- should be in log file
>> * SRJ SRJ SMDR logger Global from context is Global:ERROR in
>> SMDR_DEBUG_Global
>> 16:23:59.990 [main] ERROR Global - * SRJ SRJ Global LOGGER IN
>> SMDR_DEBUG.txt   <-- should be in log file
>> 
>> 
>> XML generated from builder:
>> 
>> 
>>
>>> filename="ps/debug/SMDR_DEBUG.txt"
>> filePattern="ps/debug/SMDR_DEBUG_%d{MMdd}.txt.gz">
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>> 
>> 
>> Trace from builder:
>> 
>> 2022-05-19 16:23:59,921 main DEBUG PluginManager 'Converter' found 45
>> plugins
>> 2022-05-19 16:23:59,922 main DEBUG Starting OutputStreamManager
>> SYSTEM_OUT.false.false-3
>> 2022-05-19 16:23:59,940 main INFO Log4j appears to be running in a Servlet
>> environment, but there's no log4j-web module available. If you want better
>> web container support, please add the log4j-web JAR to your web archive or
>> server lib directory.
>> 2022-05-19 16:23:59,941 main DEBUG Apache Log4j Core 2.17.1 initializing
>> configuration
>> 
>> 

Re: shared log4j config used by multiple tomcat webapps

[Ralph Goers]

> On May 12, 2022, at 4:16 AM, Dave Piper (HE/HIM) 
>  wrote:
> 
> Hi,
> 
> 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)
> - ...

When using the ClassLoaderContextSelector you do not need log4j jars in each 
web app. However, You should only have the one set in the tomcat/lib directory. 

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

When the ClassLoaderContextSelector is used (the default) Log4j will use the 
caller’s ClassLoader to determine the LoggerContext to use when obtaining a 
Logger. Each LoggerContext should tie it to the Configuration for all the 
Loggers for classes in that ClassLoader. Note that Log4j is, by default, going 
to look for the log4j2.xml on the classpath. So in Tomcat it should find the 
appropriate log4j2.xml since tomcat won’t look at web app ClassLoaders and 
tomcat normally uses child first loading so should find the web apps log4j2.xml 
in WEB-INF/classes.

I would suggest removing the log4j-xxx jars in the web apps and see what 
results you get. 


Ralph


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

Re: Module or Classpath

[Ralph Goers]

I’m not quite clear on the question.

Ralph

> On Apr 17, 2022, at 4:07 PM, KARTHIK SHIVAKUMAR  wrote:
> 
> Hi
> 
> Spec JDK17/Linux/EclipaeJ2EEIDE
> 
> Question  :  log4j2-core.xx / log4j2-api.xx   need to add as *module OR
> classpath *
>for a new project built from scratch ?
> 
> -- 
> 
> *with regards*
> *N.S.KARTHIK*


-
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

[Ralph Goers]

Ideally, parallel tests should use their own LoggerContext. But for the 
ClassLoaderContextSelector (the default) this would require that each
test have its own ClassLoader. In reality it would be better to create a 
ContextSelect for the framework you are using that keys off of 
something unique for each test to have its own ContextSelector.

I know nothing about a Spock testing framework so I can’t really 
advise you there.

Ralph

> On Apr 13, 2022, at 5:46 PM, Björn Kautler  wrote:
> 
> Hi
> 
> 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.
> 
> Now my problem is, that I'd like to enable parallel execution of the
> tests which is new in Spock 2.x.
> But the ListAppender naturally does not like that, as it is the same
> for the whole JVM.
> 
> I looked into the LoggerContextRule whether I find something useful there,
> but - please correct me if I'm wrong - as far as I have seen it also
> is not capable of parallel execution
> as it uses system properties and static state, so parallel tests would
> also overwrite each other I guess.
> 
> Is there something that could be used that better supports parallel execution?
> Would maybe a ThreadLocalListAppender help that has thread local
> fields for events, messages, and data?
> Or something else that is available?
> 
> Regards
> Björn
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

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

[Ralph Goers]

I asked where the jars are located. You replied "Along with various other 
product libs, log4j2 jars and log4j2 propertie file are placed under 
soa-dir/lib. This path is accessible by all 3 wars.”  That answer implies that 
they are not in WEB-INF/lib of any of the web apps.

First, I do not know why you are still using a custom Logger since we already 
advised you not to do that.

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.

Ralph

> On Apr 6, 2022, at 3:25 PM, Pooja Pandey  wrote:
> 
> But these other 2 wars already have log4j2 jars bundled with these. I mean in 
> WEB-INF/lib of these wars, log4j2 jars are available and even the version is 
> also different which is log4j2 2.17.1 while my application is using 2.17.2.
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>
> ________
> From: Ralph Goers 
> Sent: Wednesday, April 6, 2022 11:54:26 PM
> To: Log4J Users List 
> Subject: Re: can we set log4j property 'Log4jContextSelector' per webapps war
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> OK. If all 3 wars are using the same Log4j jars then you can only have a 
> single ContextSelector.
> 
> Ralph
> 
>> On Apr 6, 2022, at 11:17 AM, Pooja Pandey  
>> wrote:
>> 
>> Webapps wars path is like: installation directory/soa-dir/webapps/
>> 
>> Along with various other product libs, log4j2 jars and log4j2 propertie file 
>> are placed under soa-dir/lib. This path is accessible by all 3 wars. I 
>> cannot make any changes in 2 wars which we are fetching from artifactory.
>> 
>> 
>> 
>> Get Outlook for iOS<https://aka.ms/o0ukef>
>> 
>> From: Ralph Goers 
>> Sent: Wednesday, April 6, 2022 11:33:55 PM
>> To: Log4J Users List 
>> Subject: Re: can we set log4j property 'Log4jContextSelector' per webapps war
>> 
>> *** External email: Verify sender before opening attachments or links ***
>> 
>> 
>> Where are the Log4j jars located?
>> 
>> Ralph
>> 
>>> On Apr 6, 2022, at 6:34 AM, Pooja Pandey  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> In my application, I have 2 processes running and there are 3 webapps war 
>>> files which get deployed in tomcat version 9.0.60. Out of these 3 war 
>>> files, one war file is internal to my application while other 2 are coming 
>>> as final artifacts from artifiactory.
>>> 
>>> My war uses a custom logger and custom ContextSelector, however other 2 
>>> wars from artifactory uses standard logger and standard ContextSelector.
>>> 
>>> I have defined below system property as a static block in custom logger, 
>>> however for some unknown reason when my war gets deployed this log4j jars 
>>> don't find this property and leads to ClassCastException 
>>> "java.lang.ClassCastException: 
>>> org.apache.logging.log4j.core.selector.ContextSelector cannot be cast to 
>>> logger.log4j2.CustomLog4j2ContextSelector". To fix this I have placed 
>>> 'log4j2.component.properties' file on log4j jars class path, but with this 
>>> fix, following harmless error get logged for other 2 wars 
>>> "java.lang.ClassCastException: Cannot cast 
>>> logger.log4j2.CustomLog4j2ContextSelector to 
>>> org.apache.logging.log4j.core.selector.ContextSelector".
>>> 
>>> I am looking for help to come up with a solution where, when my war gets 
>>> deployed then custom logger context 
>>> "logger.log4j2.CustomLog4j2ContextSelector" should be used while when other 
>>> 2 wars get deployed then  
>>> "org.apache.logging.log4j.core.selector.ContextSelector" should be used. 
>>> Please let me know if you have any idea on this.
>>> 
>>> static {
>>>  System.setProperty("Log4jContextSelector", 
>>> "logger.log4j2.CustomLog4j2ContextSelector");
>>> }
>>> 
>>> 
>>> Content of file 'log4j2.component.properties' ->
>>> Log4jContextSelector=logger.log4j2.CustomLog4j2ContextSelector
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

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

[Ralph Goers]

OK. If all 3 wars are using the same Log4j jars then you can only have a single 
ContextSelector.

Ralph

> On Apr 6, 2022, at 11:17 AM, Pooja Pandey  
> wrote:
> 
> Webapps wars path is like: installation directory/soa-dir/webapps/
> 
> Along with various other product libs, log4j2 jars and log4j2 propertie file 
> are placed under soa-dir/lib. This path is accessible by all 3 wars. I cannot 
> make any changes in 2 wars which we are fetching from artifactory.
> 
> 
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>
> ____
> From: Ralph Goers 
> Sent: Wednesday, April 6, 2022 11:33:55 PM
> To: Log4J Users List 
> Subject: Re: can we set log4j property 'Log4jContextSelector' per webapps war
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> Where are the Log4j jars located?
> 
> Ralph
> 
>> On Apr 6, 2022, at 6:34 AM, Pooja Pandey  
>> wrote:
>> 
>> Hi,
>> 
>> In my application, I have 2 processes running and there are 3 webapps war 
>> files which get deployed in tomcat version 9.0.60. Out of these 3 war files, 
>> one war file is internal to my application while other 2 are coming as final 
>> artifacts from artifiactory.
>> 
>> My war uses a custom logger and custom ContextSelector, however other 2 wars 
>> from artifactory uses standard logger and standard ContextSelector.
>> 
>> I have defined below system property as a static block in custom logger, 
>> however for some unknown reason when my war gets deployed this log4j jars 
>> don't find this property and leads to ClassCastException 
>> "java.lang.ClassCastException: 
>> org.apache.logging.log4j.core.selector.ContextSelector cannot be cast to 
>> logger.log4j2.CustomLog4j2ContextSelector". To fix this I have placed 
>> 'log4j2.component.properties' file on log4j jars class path, but with this 
>> fix, following harmless error get logged for other 2 wars 
>> "java.lang.ClassCastException: Cannot cast 
>> logger.log4j2.CustomLog4j2ContextSelector to 
>> org.apache.logging.log4j.core.selector.ContextSelector".
>> 
>> I am looking for help to come up with a solution where, when my war gets 
>> deployed then custom logger context 
>> "logger.log4j2.CustomLog4j2ContextSelector" should be used while when other 
>> 2 wars get deployed then  
>> "org.apache.logging.log4j.core.selector.ContextSelector" should be used. 
>> Please let me know if you have any idea on this.
>> 
>> static {
>>   System.setProperty("Log4jContextSelector", 
>> "logger.log4j2.CustomLog4j2ContextSelector");
>> }
>> 
>> 
>> Content of file 'log4j2.component.properties' ->
>> Log4jContextSelector=logger.log4j2.CustomLog4j2ContextSelector
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

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

[Ralph Goers]

Where are the Log4j jars located?

Ralph

> On Apr 6, 2022, at 6:34 AM, Pooja Pandey  wrote:
> 
> Hi,
> 
> In my application, I have 2 processes running and there are 3 webapps war 
> files which get deployed in tomcat version 9.0.60. Out of these 3 war files, 
> one war file is internal to my application while other 2 are coming as final 
> artifacts from artifiactory.
> 
> My war uses a custom logger and custom ContextSelector, however other 2 wars 
> from artifactory uses standard logger and standard ContextSelector.
> 
> I have defined below system property as a static block in custom logger, 
> however for some unknown reason when my war gets deployed this log4j jars 
> don't find this property and leads to ClassCastException 
> "java.lang.ClassCastException: 
> org.apache.logging.log4j.core.selector.ContextSelector cannot be cast to 
> logger.log4j2.CustomLog4j2ContextSelector". To fix this I have placed 
> 'log4j2.component.properties' file on log4j jars class path, but with this 
> fix, following harmless error get logged for other 2 wars 
> "java.lang.ClassCastException: Cannot cast 
> logger.log4j2.CustomLog4j2ContextSelector to 
> org.apache.logging.log4j.core.selector.ContextSelector".
> 
> I am looking for help to come up with a solution where, when my war gets 
> deployed then custom logger context 
> "logger.log4j2.CustomLog4j2ContextSelector" should be used while when other 2 
> wars get deployed then  
> "org.apache.logging.log4j.core.selector.ContextSelector" should be used. 
> Please let me know if you have any idea on this.
> 
> static {
>System.setProperty("Log4jContextSelector", 
> "logger.log4j2.CustomLog4j2ContextSelector");
> }
> 
> 
> Content of file 'log4j2.component.properties' ->
> Log4jContextSelector=logger.log4j2.CustomLog4j2ContextSelector


-
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

[Ralph Goers]

> On Apr 3, 2022, at 11:59 AM, Piotr P. Karwasz  
> wrote:.
> 
> 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`.

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. 

Ralph


-
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

[Ralph Goers]

I would expect the Properties issue would affect all the implementations.

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.

FWIW, I am not against making the proposed change. We already do other stuff to 
make 
the properties configuration more usable.

Ralph

> On Apr 2, 2022, at 11:08 PM, Piotr P. Karwasz  wrote:
> 
> 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
> 


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

Re: How to migrate parameterized messages

[Ralph Goers]

If you are doing

   Logger logger = LogManager.getLogger(“edu.nd.MyClass”);
or
   Logger logger = LogManager.getLogger(edu.nd.MyClass.class);

then all you have to do is change the imports from org.apache.log4j to 
org.apache.logging.log4j. Everything else would be optional.

If you are obtaining the Logger from the Logger’s static method you 
would need to change that to one of the forms above.

Using parameterized messages is a good idea as it allows you to change

If (logger.isDebugEnabled()) {
  logger.debug(“Compiler Exception for “ + datafilter, e);
}

to 

logger.debug(“Compiler Exception for {}”, datafilter, e);

But doing this is optional and can be done over time to clean up the code.

Ralph

> On Mar 30, 2022, at 10:23 AM, Joel Griffith  wrote:
> 
> Hi,
> 
> I'm upgrading an application from Log4j v1 to v2.
> 
> The v1 code often uses the debug()/info()/etc. methods with the
> `Logger.debug(Object message, Throwable throwable)` signature to throw
> errors while logging.  In many cases, the `message` String is composed
> using concatenation, as with
> 
>logger.debug("Compiler Exception for " + datafilter, e);
> 
> where `datafilter` is a String and `e` is an Exception (`logger`, of
> course, is a Logger).
> 
> I'm looking for the simplest drop-in replacement for such lines to migrate
> them to Log4j v2 and its requirement for parameterized messages.  The Log4j
> migration guide provides a drop-in replacement for the simplest case; i.e.
> 
>logger.info("hi " + userName) -> logger.info("hi {}", userName)
> 
> but when I apply this naively to my case,
> 
>/* Log4j v2 ? */
>logger.debug("Compiler Exception for " + datafilter, e) ->
> logger.debug("Compiler Exception for {}", datafilter, e)
> 
> the method signature looks odd and I'm not sure it will work.  I can't test
> it because the code is not functional because it's in the middle of Log4j
> remediation.
> 
> My question is, is the above example labeled 'Log4j v2 ?' correct for
> migrating from Log4j v1 to v2?  If not, what's the simplest drop-in
> replacement for the original `debug()` method call that includes a
> Throwable as an argument?
> 
> Thanks,
> Joel


-
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

[Ralph Goers]

Comments below.

> On Mar 29, 2022, at 3:01 PM, Pablo Rogina  wrote:
> 
> Ralph, thank you for your reply.
> 
>> To be usable in your configuration a Log4j 1.2 Appender cannot be a Log4j2 
>> plugin.
> Ok. It is not, as my CustomAppender extends RollingFileAppender (from
> Log4j v 1.2.x)
> 
>> You would configure it exactly as you do in log4j 1.x, via its class name.
> Ok. I think it's what I'm doing.
> This is the properties I'm using to configure my app logging:
> log4j.appender.MYAPPLOGFILE=com.mycompany.log4j.CustomAppender
> log4j.appender.MYAPPLOGFILE.Append=false
> log4j.appender.MYAPPLOGFILE.SpecialValue=ABC
> log4j.appender.MYAPPLOGFILE.HeaderVersion=1
> log4j.appender.MYAPPLOGFILE.File=logs/MyApp.log
> log4j.appender.MYAPPLOGFILE.MaxBackupIndex=19
> log4j.appender.MYAPPLOGFILE.MaxFileSize=2000KB
> log4j.appender.MYAPPLOGFILE.layout=org.apache.log4j.PatternLayout
> log4j.appender.MYAPPLOGFILE.layout.ConversionPattern=%d{[dd MMM 
> HH\:mm\:ss,SSS]}[%t]\:%-5p\:%l -->%m%n
> log4j.rootLogger=INFO, MYAPPLOGFILE


For this can you run your application with -Dlog4j2.debug=true? I’d like to see 
what is happening.

> 
>> That said, Do you really need your custom RollingFileAppender? The 
>> RollingFileAppender
>> in Log4j 2 has many more options than Log4j 1 did.
> 
> Well, I also have a CustomAppender for Log4j 2 that resembles a
> RollingFileAppender, defined like this:
> 
> @Plugin(name = CustomAppender.PLUGIN_NAME, category =
> Core.CATEGORY_NAME, elementType = Appender.ELEMENT_TYPE, printObject =
> true)
> public final class CustomAppender extends
> AbstractOutputStreamAppender {
> ...
> 
> however I also got the "Unable to load plugin class name ..." issue if
> using the CustomAppender v2.
> And I also find difficult to configure it via Properties using the
> Log4j 1.2 Bridge

Yes, that is understandable. The problem is that the Log4j 1 support cannot 
directly deal with 
a Log4j 2 Appender. It has to wrap it to make it look like a Log4j 1 Appender. 
So you could 
either create your own Builder that is similar to the other AppenderBuilders or 
you can define 
your custom Log4j.2 Appender in its own Log4j 2 configuration file and then 
merge it with your 
Log4j 1 configuration as a composite configuration - see 
https://logging.apache.org/log4j/2.x/manual/configuration.html#CompositeConfiguration
 
.

Ralph

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

[Ralph Goers]

To be usable in your configuration a Log4j 1.2 Appender cannot be a Log4j2 
plugin.
You would configure it exactly as you do in log4j 1.x, via its class name.

That said, Do you really need your custom RollingFileAppender? The 
RollingFileAppender 
in Log4j 2 has many more options than Log4j 1 did. 

Ralph

> On Mar 29, 2022, at 10:58 AM, Pablo Rogina  wrote:
> 
> Hi,
> 
> I have an old application using Log4j 1.2.x and we're using Log4j 1.2
> Bridge from Log4j 2.17.2 to mitigate some vulnerabilities while
> minimizing source code changes.
> The application uses Log4j v1 properties file for configuration.
> 
> We developed a custom appender by extending RollingFileAppender and
> it's contained in its own JAR file.
> With all components in place (log4j-api.jar, log4j-1.2-api.jar,
> log4j-core.api, custom-appender.jar) most of the properties are
> processed and appenders, layouts are created.
> 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
> 
> And then the maxFileSize for log files and backup index files are messed up.
> 
> I found the "packages" attribute from Configuration but I was not able
> to make it work:
> 1. given that we're not using an XML or JSON configuration file I
> don't know how to set the "packages" property for Configuration in a
> log4j v1 properties file
> 2. tried system variable
> -Dlog4j.plugin.packages=com.mycompany.log4j.CustomAppender
> 
> Thank you.
> 
> Pablo Rogina
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: manual log4j2 initialization inside webapp ends up in extra LoggerContext

[Ralph Goers]

By default, Log4j 2 uses ClassLoaderContextSelector. The way this works is that 
whenever LogManager.getLogger() is called LogManager will call 
ClassLoaderContextSelector which will locate the LoggerContext associated with 
the ClassLoader of the class that called LogManager.getLogger(). In web 
container such as Tomcat this allows the Log4j jars to be placed in Tomcat’s 
classloader and a separate LoggerContext will be created for Tomcat as well as 
each web application. Each would have its own logging configuration.

So when log4j is initialized by your servlet the LoggerContext created will 
only apply to the web app that contains that servlet. If you also have an EAR 
it would also have its own ClassLoader and so could have its own logging 
configuration.

If you only want a single LoggerContext for the whole JBoss then you need to 
switch to a different ContextSelector. 
https://logging.apache.org/log4j/2.x/manual/extending.html#ContextSelector 
lists the various ContextSelectors provided by Log4j but you can also write 
your own if you want something custom.

If you want you can add the property that specifies the ContextSelector class 
name to a file named log4j2.component.properties that you then place on the 
class path. Otherwise you would specify it as a system property passed to your 
application.

Ralph

> On Mar 23, 2022, at 11:34 PM, Gernot Hueller  wrote:
> 
> Dear all,
> 
> I am at a dead end, I hope someone on this mailing list can help me...
> 
> 
> 
> I have a web application deployed as an EAR in a JBoss application server, 
> containing of a .war and many utility jars (managed by gradle)
> 
> For various complex reasons, I cannot use "automagic" configuration. Mostly, 
> I set a few System properties in the code before initialization.
> 
> Initialization is done in a servlet which is guaranteed to start first by 
> WEB-INF/web.xml
> 
> Initialization sets system properties then runs
> 
>Configurator.initialize(classLoader, new ConfigurationSource(new 
> FileInputStream(filename)));
> 
> or alternatively REconfigure following the FAQ at 
> https://logging.apache.org/log4j/log4j-2.4/faq.html
> 
> 
> 
> However, no matter what I do, I end up with TWO LoggerContext instances
> 
> (I see that during initialization trace and later in 
> log4jContextFactory.getSelector().getLoggerContexts())
> 
> and the "wrong" LoggerContext has a RootLogger with level ERROR and NO 
> appenders and all of the loggers that are actually used and touched in the 
> application are under the "wrong" LoggerContext and have log level ERROR and 
> do not log. Only some loggers which are directly used in the web application 
> .war are configured correctly.
> 
> 
> 
> for all the "wrong" loggers I get a message like
> 
> loggerContext name=24421690 - logger name=org.apache.velocity.loader.webapp 
> level=ERROR appenders=
> 
> WARN StatusLogger The Logger  was created with the message factory 
> org.apache.logging.log4j.message.ParameterizedMessageFactory@63e37b6c and is 
> now requested with the message factory 
> org.apache.logging.log4j.message.ParameterizedMessageFactory@19334714, which 
> may create log events with unexpected formatting.
> 
> 
> 
> I did not ask for a second LoggerContext and I do not understand why it is 
> created.
> 
> In fact is is created inside the 
> loggerContext.setConfigLocation(file.toURI()) of the "only" LoggerContext I 
> know
> 
> 
> 
> 
> 
> Please help me initialize my log4j properly from a ConfigurationSource
> 
> 
> 
> 
> 
> 
> 
> Here is some trace log, where the "wrong" LoggerContext is created without a 
> configuration - and all subsequent loggers are put under THAT loggerContext
> 
> 
> 
> DEBUG StatusLogger Registering MBean 
> org.apache.logging.log4j2:type=56df3650,component=Appenders,name=msgInFile
> 
> DEBUG StatusLogger Registering MBean 
> org.apache.logging.log4j2:type=56df3650,component=Appenders,name=msgOutFile
> 
> TRACE StatusLogger Using DummyNanoClock for nanosecond timestamps.
> 
> DEBUG StatusLogger Reconfiguration complete for context[name=56df3650] at URI 
> C:\Java\myprj\conf\gernot_log4j2\log4j2.xml 
> (org.apache.logging.log4j.core.LoggerContext@f034b2) with optional 
> ClassLoader: null
> 
> DEBUG StatusLogger PluginManager 'Lookup' found 16 plugins
> 
> DEBUG StatusLogger PluginManager 'Converter' found 47 plugins
> 
> DEBUG StatusLogger Starting OutputStreamManager SYSTEM_OUT.false.false-3
> 
> DEBUG StatusLogger Starting LoggerContext[name=7ff11457, 
> org.apache.logging.log4j.core.LoggerContext@1c50492]...
> 
> DEBUG StatusLogger Reconfiguration started for context[name=7ff11457] at URI 
> null (org.apache.logging.log4j.core.LoggerContext@1c50492) with optional 
> ClassLoader: null
> 
> DEBUG StatusLogger Using configurationFactory 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory@2c01ff02
> 
> TRACE StatusLogger Trying to find [log4j2-test7ff11457.properties] using 
> context class loader ModuleClassLoader for 

Re: [External] org.apache.logging.log4j.jmx.HierarchyDynamicMBean not found in log4j 2

[Ralph Goers]

The reason Log4j 2 does not contain that Mean is because Log4j 2 has no 
Hierarchy object. Instead, it has a LoggerContext. It does have a 
LoggerContextAdminMBean and it has a LoggerConfigAdminMBean. The latter lets 
you inspect and manipulate logger configurations.

There would be no way to create the HierarchyDynamicMBean as it is defined in 
Log4j 1.2 as it references things that don’t exist in Log4j 2.

As for suggestions - Migrating code is largely a matter of changing the 
dependency and the imports and creating a suitable Log4j 2 configuration. The 
Log4j 2 API supports most of the Log4j 1 “api” (I use that term loosely since 
there was no well defined API).

The hard part comes with whatever customizations you have made or code that is 
accessing the internals of Log4j 1.x. Without knowing what you have done in 
that regard it is difficult to say what you need to do to migrate.

Ralph


> On Mar 22, 2022, at 1:12 PM, Shaib Al-Agily 
>  wrote:
> 
> Thank you Ralph and Gary for your prompt response.
> 
> Perhaps I was not clear, the HierarchyDynamicMBean exists in the 
> log4j-1.214.jar and our app uses it and there are no errors.
> As we are trying to migrate to log4j-core-2.17.1, we noticed that 
> HierarchyDynamicMBean is not part of log4j-core-2.17.1.jar and it is throwing 
> errors.
> 
> My question are, 
> is HierarchyDynamicMBean included in log4j 2? 
> Is there an alternative solution/class? 
> Can the HierarchyDynamicMBean class be packaged part of log4j2? 
> Can the HierarchyDynamicMBean be extracted from log4j-1 and add it log4j-2?
> Any suggestions on how to migrate log4j2?
> 
> Thank you
> 
> Shaib
> 
> -Original Message-
> From: Ralph Goers  <mailto:ralph.go...@dslextreme.com>> 
> Sent: Monday, March 21, 2022 6:48 PM
> To: Log4J Users List  <mailto:log4j-user@logging.apache.org>>
> Subject: [External] Re: org.apache.logging.log4j.jmx.HierarchyDynamicMBean 
> not found in log4j 2
> 
> I’m confused. Log4j 1.x used the package org.apache.log4j. Log4j 2.x uses 
> org.apache.logging.log4j. So how was that class part of Log4j 1.x?
> 
> Indeed - 
> https://secure-web.cisco.com/1aJ9StItuostdVVrk_AythzsM_-usieWrcWBvKR5Qo3pDj-R-rqduf1Y2dmHEnQf7kTAgDnS7ieZqSYFjy1d9JuT-msPOSykVoeBj4ENeM7b1Np8LTq4WujNs7qJ4Py-OZipVC4xVhgEOq1F1Yx4F_XNOHbBqw8fMHk4L6qidmMp2XYmiM6H9QAkHWYxOO8qcFhVD1zfR7iNjIkY9ypNtfAMEmXmZAj-Xo4nE3Kr-zmXVaVyV_kcUU4Xrbe2eU3rr12RxqNu7sSsy9321TvgucXV4sevmlK6Tr_W4Ur4G8BDQWhQyUbNElOJ63Pw449k83uc65i9ZzA4-X6ZRDpk2dRTLFlha1aoPXA-g3Js5eXWfCLfQglFITMzJVQWwvdusIvq5A6VK4BYVlc2zsbr5fuB7o23Gli4izJk9dlmS1FtfeN7OIYtkx8-osLuNwrT92Fy9IZI84qSAoIuKDvYIfg/https%3A%2F%2Flogging.apache.org%2Flog4j%2F1.2%2Fapidocs%2Forg%2Fapache%2Flog4j%2Fjmx%2FHierarchyDynamicMBean.html
>  
> <https://secure-web.cisco.com/1aJ9StItuostdVVrk_AythzsM_-usieWrcWBvKR5Qo3pDj-R-rqduf1Y2dmHEnQf7kTAgDnS7ieZqSYFjy1d9JuT-msPOSykVoeBj4ENeM7b1Np8LTq4WujNs7qJ4Py-OZipVC4xVhgEOq1F1Yx4F_XNOHbBqw8fMHk4L6qidmMp2XYmiM6H9QAkHWYxOO8qcFhVD1zfR7iNjIkY9ypNtfAMEmXmZAj-Xo4nE3Kr-zmXVaVyV_kcUU4Xrbe2eU3rr12RxqNu7sSsy9321TvgucXV4sevmlK6Tr_W4Ur4G8BDQWhQyUbNElOJ63Pw449k83uc65i9ZzA4-X6ZRDpk2dRTLFlha1aoPXA-g3Js5eXWfCLfQglFITMzJVQWwvdusIvq5A6VK4BYVlc2zsbr5fuB7o23Gli4izJk9dlmS1FtfeN7OIYtkx8-osLuNwrT92Fy9IZI84qSAoIuKDvYIfg/https%3A%2F%2Flogging.apache.org%2Flog4j%2F1.2%2Fapidocs%2Forg%2Fapache%2Flog4j%2Fjmx%2FHierarchyDynamicMBean.html>
> indicates the package name you show below is wrong.
> 
> Although Gary just added the JMX components to log4j-1.2-api I don’t believe 
> you should actually use them. 
> Log4j 2 comes with its own JMX support and since the design of Log4j 2 is 
> different than Log4j 1 I suspect not everything in 1.x will work as expected.
> 
> Ralph
> 
>> On Mar 21, 2022, at 4:34 PM, Gary Gregory > <mailto:garydgreg...@gmail.com>> wrote:
>> 
>> Shaib,
>> 
>> That whole package was never ported into the log4j-1.2-api module.
>> 
>> I just added the missing package for API binary compatibility.
>> 
>> Do note the package Javadoc: "This package lets you manage log4j 
>> settings using JMX. It is unfortunately not of production quality."
>> 
>> There is no testing for behavioral compatibility, this is currently 
>> only to avoid class not found errors. It is unlikely to work as expected.
>> 
>> You can find this code in the 'release-2.x' branch and snapshot builds 
>> on 
>> https://secure-web.cisco.com/18xOszRxVXXg0W1jCjpnCfB8pC5Rw4x-luLF26Hrg 
>> <https://secure-web.cisco.com/18xOszRxVXXg0W1jCjpnCfB8pC5Rw4x-luLF26Hrg>
>> OY2ky_t5a3FqIGLmgeGdQ6ttTnECbjZ3Nk-699lYMF40iEi4rEGeMMAAvj8smCJ64OUOyh
>> AJ2hAr93ffe461mOOwkF5JtMmkPLqBsQIZ6_o1yMzw_a3BN4Hokco1HsJcqDxKv7LavsEB
>> 7pTMF-khL2mlTZENnuVFjldZguehKFiAs4NlE3KxHXnrWTPxqxYynOgVf35UxinOw

Re: org.apache.logging.log4j.jmx.HierarchyDynamicMBean not found in log4j 2

[Ralph Goers]

I’m confused. Log4j 1.x used the package org.apache.log4j. Log4j 2.x uses 
org.apache.logging.log4j. So how was that class part of Log4j 1.x?

Indeed - 
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/jmx/HierarchyDynamicMBean.html
 
indicates the package name you show below is wrong.

Although Gary just added the JMX components to log4j-1.2-api I don’t believe 
you should actually use them. 
Log4j 2 comes with its own JMX support and since the design of Log4j 2 is 
different than Log4j 1 I suspect 
not everything in 1.x will work as expected.

Ralph

> On Mar 21, 2022, at 4:34 PM, Gary Gregory  wrote:
> 
> Shaib,
> 
> That whole package was never ported into the log4j-1.2-api module.
> 
> I just added the missing package for API binary compatibility.
> 
> Do note the package Javadoc: "This package lets you manage log4j settings
> using JMX. It is unfortunately not of production quality."
> 
> There is no testing for behavioral compatibility, this is currently only to
> avoid class not found errors. It is unlikely to work as expected.
> 
> You can find this code in the 'release-2.x' branch and snapshot builds on
> https://repository.apache.org/content/repositories/snapshots/
> 
> Gary
> 
> On Mon, Mar 21, 2022 at 5:13 PM Shaib Al-Agily
>  wrote:
> 
>> Hello,
>> 
>> Per Apache's website recommendations, our company is in the process of
>> migrating some of its applications from log4j-1.2.14 to log4j-core-2.17.1.
>> 
>> Class "org.apache.logging.log4j.jmx.HierarchyDynamicMBean" is referenced
>> in one of our application and that is generating an error. It appears class
>> org.apache.logging.log4j.jmx.HierarchyDynamicMBean is not implemented in
>> log4j 2.
>> 
>> Questions:
>> 1.   Is the class
>> org.apache.logging.log4j.jmx.HierarchyDynamicMBean implemented in log4j 2?
>> Where?
>> 2.   Is it merged in another class?
>> 3.   Is there an alternative class/solution?
>> 
>> Thank you very much
>> 
>> Shaib
>> 
>> 
>> 


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

Re: Equivalent of SocketNode class in log4j version 2.17.1

[Ralph Goers]

The SocketServer was removed from Log4j 2 in the 2.8.2 release to address 
CVE-2017-5645. Most implementations used Java serialized events as the format 
of the data being sent, which is inherently insecure. The code still exists in 
https://github.com/apache/logging-log4j-tools 
 and can be used as a sample 
starting point but that code will likely never be released. 

I would also suggest that using just raw TCP as the protocol is a mistake. When 
issues happen and the consuming service is taken down typically the application 
will continue to send at least one more message “successfully” before the error 
is detected. Using acknowledgements, such as what the Flume appender does, 
avoids this problem. 

Ralph

> On Mar 17, 2022, at 1:14 AM, Gajendra S V  wrote:
> 
> Hi Team,
> 
> We are migrating our application from log4j to log4j2 and  using the
> log4j.2.17.1 version now. I have come across TCPSocketServer which is used
> in the higher version  instead of Socket Node. But I could not see the same
> class on 2.17.1 version. Please let me know how to write remote logs .
> Below is the sample code used in the current log4j version.
> 
> ServerSocket serverSocket = new ServerSocket(port, backlog, bindAddress);
> Socket lSocket = serverSocket.accept();
> socketArrayInUse.add(lSocket);
> InetAddress lAddr = lSocket.getInetAddress();
> LoggerRepository lRepo = getLoggerRepository(lAddr);
> SocketNode lNode = new SocketNode(lSocket, lRepo);
> String lClientHost = lAddr.getHostName();
> SocketThread lThread = new SocketThread(lNode, lClientHost);
> lThread.start();
> 
> Thanks
> Gajendra S V

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

[Ralph Goers]

We just released Log4j 2.17.2 last week. I wouldn’t expect the next release 
until sometime in April. But it all depends on how much gets done. 

Ralph

> On Mar 8, 2022, at 7:39 AM, Pooja Pandey  wrote:
> 
> Hi Piotr,
> 
> -> 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:
> 
> I don't have log4j libraries in tomcat classpath.
> 
> After adding those web, jcl, jul jars, the issue is fixed.
> 
> Do you have any idea when this log4j2.17.3 would be released?? We would like 
> to use that for the fix you have provided for  LOG4J2-3426.
> 
> 
> -Original Message-
> From: Piotr P. Karwasz  
> Sent: Tuesday, March 8, 2022 8:04 PM
> To: Log4J Users List 
> Subject: Re: Log4j1.x bridge error: Unable to create Lookup for bundle 
> java.lang.ClassCastException: class 
> org.apache.logging.log4j.core.lookup.ResourceBundleLookup
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> 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
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


-
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

[Ralph Goers]

So if I understand correctly, you wrote a custom RollingFileAppender that 
extends the FileAppender? If so, that should work just fine. But that would 
just be a matter of compiling it and then using your custom appender in the 
log4j.xml.

What is the tie in that requires a custom Logger?

Also, FWIW the Log4j 2 RollingFileAppender does not support being used across 
multiple processes targeting the same file either. I’d love to know how you 
avoided having the file roll multiple times (once for each process).

Ralph

> On Mar 5, 2022, at 8:10 AM, Pooja Pandey  wrote:
> 
> Hi Ralph,
> 
> We needed custom logger long long back when log4j1 logger was not sufficient 
> to achieve the goal we had. We have multiple processes also using this logger.
> 
> For Appender, we actually needed rolling file appender, but the available 
> appender in log4j1 didn’t work as expected with multiple proceess. So we 
> wrote custom multi process rolling appender which actually extends 
> FileAppender.
> 
> This whole code is legacy and old code. Due to time constraint we want to use 
> bridge to migrate to log4j2 with bare minimum or very minor code changes to 
> retain the functionality as is.
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>
> 
> From: Ralph Goers 
> Sent: Saturday, March 5, 2022 9:21:20 AM
> To: Log4J Users List 
> Subject: Re: java.lang.ClassCastException: 
> org.apache.log4j.bridge.AppenderWrapper cannot be cast to 
> org.apache.log4j.FileAppender
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> I am still trying to understand why you have a custom Logger and a custom 
> FileAppender. What additional features do they provide? Can you perhaps 
> create a zip of your customizations so we can understand?
> 
> Thanks
> Ralph
> 
>> On Mar 4, 2022, at 7:00 PM, Pooja Pandey  
>> wrote:
>> 
>> By overriding getAppender in our customLogger, the cast Exception could be 
>> fixed, however we are still having some minor issues in reading property 
>> value but may be this new issue is due to some other problems. I am still 
>> trying to figure out.
>> 
>> 
>> 
>> 
>>   @Override
>>   public Appender getAppender(final String name) {
>>   AppenderWrapper appenderWrapper = (AppenderWrapper) 
>> super.getAppender(name);
>>   return 
>> ((AppenderAdapter.Adapter)appenderWrapper.getAppender()).getAppender();
>>   }
>> 
>> 
>> Get Outlook for iOS<https://aka.ms/o0ukef>
>> 
>> From: Pooja Pandey 
>> Sent: Saturday, March 5, 2022 7:25:24 AM
>> To: Log4J Users List 
>> Subject: Re: java.lang.ClassCastException: 
>> org.apache.log4j.bridge.AppenderWrapper cannot be cast to 
>> org.apache.log4j.FileAppender
>> 
>> *** External email: Verify sender before opening attachments or links ***
>> 
>> 
>> Actually, in first go due to time constraint, we are using log4j bridge 
>> instead of direct log4j2 API to migrate our legacy huge code from log4j1 to 
>> log4j2.
>> 
>> In code we use custom FileAppender
>> 
>> When we Logger.getAppender(), it is returning AppenderWrapper now with the 
>> bridge.
>> 
>> Get Outlook for iOS<https://aka.ms/o0ukef>
>> ________
>> From: Piotr P. Karwasz 
>> Sent: Saturday, March 5, 2022 12:15:55 AM
>> To: Log4J Users List 
>> Subject: Re: java.lang.ClassCastException: 
>> org.apache.log4j.bridge.AppenderWrapper cannot be cast to 
>> org.apache.log4j.FileAppender
>> 
>> *** External email: Verify sender before opening attachments or links ***
>> 
>> 
>> 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
>> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


-
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

[Ralph Goers]

Piotr,

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?

Ralph

> On Mar 5, 2022, at 6:53 AM, Piotr P. Karwasz  wrote:
> 
> 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
> 


-
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

[Ralph Goers]

I am still trying to understand why you have a custom Logger and a custom 
FileAppender. What additional features do they provide? Can you perhaps create 
a zip of your customizations so we can understand?

Thanks
Ralph

> On Mar 4, 2022, at 7:00 PM, Pooja Pandey  wrote:
> 
> By overriding getAppender in our customLogger, the cast Exception could be 
> fixed, however we are still having some minor issues in reading property 
> value but may be this new issue is due to some other problems. I am still 
> trying to figure out.
> 
> 
> 
> 
>@Override
>public Appender getAppender(final String name) {
>AppenderWrapper appenderWrapper = (AppenderWrapper) 
> super.getAppender(name);
>return 
> ((AppenderAdapter.Adapter)appenderWrapper.getAppender()).getAppender();
>}
> 
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>
> 
> From: Pooja Pandey 
> Sent: Saturday, March 5, 2022 7:25:24 AM
> To: Log4J Users List 
> Subject: Re: java.lang.ClassCastException: 
> org.apache.log4j.bridge.AppenderWrapper cannot be cast to 
> org.apache.log4j.FileAppender
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> Actually, in first go due to time constraint, we are using log4j bridge 
> instead of direct log4j2 API to migrate our legacy huge code from log4j1 to 
> log4j2.
> 
> In code we use custom FileAppender
> 
> When we Logger.getAppender(), it is returning AppenderWrapper now with the 
> bridge.
> 
> Get Outlook for iOS<https://aka.ms/o0ukef>
> 
> From: Piotr P. Karwasz 
> Sent: Saturday, March 5, 2022 12:15:55 AM
> To: Log4J Users List 
> Subject: Re: java.lang.ClassCastException: 
> org.apache.log4j.bridge.AppenderWrapper cannot be cast to 
> org.apache.log4j.FileAppender
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> 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
> 


-
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

[Ralph Goers]

At this point this would be expected. We don’t actually have 
org.apache.log4j.FileAppender in log4j-1.2-api. We map it to 
org.apache.logging.log4j.core.appender.FileAppender.

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.

That said, may I ask why you need access to the FileAppender? I’m just 
wondering if Log4j 2 already has what you are looking for implemented.

Ralph

> On Mar 4, 2022, at 2: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.
> 
> -Original Message-
> From: Gary Gregory  
> Sent: Friday, March 4, 2022 2:48 PM
> To: pooja.pan...@asg.com.invalid
> Cc: Log4J Users List 
> Subject: Re: java.lang.ClassCastException: 
> org.apache.log4j.bridge.AppenderWrapper cannot be cast to 
> org.apache.log4j.FileAppender
> 
> *** External email: Verify sender before opening attachments or links ***
> 
> 
> What is the stack trace?
> 
> Gary
> 
> On Fri, Mar 4, 2022, 03:36 Pooja Pandey 
> wrote:
> 
>> Hi Team,
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>> java.lang.ClassCastException: org.apache.log4j.bridge.AppenderWrapper
>> cannot be cast to org.apache.log4j.FileAppender
>> 
>> 
>> 
>> Thanks,
>> 
>> Pooja
>> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

[Ralph Goers]

As its name implies, ConfigurationBuilder creates a new Configuration. Any 
Configuration you build this way would replace an existing Configuration. 

I’d like to understand your use case for wanting Programmatic configuration. If 
you need to do that either we need to implement some feature so you don’t have 
to or you aren’t aware that you already don’t. 

To be clear, with Log4j 2 you wouldn’t be creating Loggers, you would be 
creating LoggerConfigs and attaching appenders to them. Yes, this can be done 
programmatically but we generally try to discourage it.

Ralph

> On Mar 2, 2022, at 3:55 PM, Robert Nicholson  
> wrote:
> 
> When using ConfigurationBuilder is it all or nothing or can you integrate 
> what your builder builds into the existing log4j that’s already been 
> initialized from log4j.xml. Actually I’ve already initialized using my xml 
> “manually” using setConfigLocation earlier.
> 
> With 1.x you can get a reference an existing logger (already defined by 
> log4j.xml) and then attach appenders to it.
> 
> That’s what I ideally want to do with ConfigurationBuilder so that I can 
> still statically setup other loggers that don’t need to be dynamically 
> created.
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Directionality of Rank between 1.x and 2.x

[Ralph Goers]

That would be my doing. There really is no rational reason. I do remember 
wanting to have the Level be an enum instead of a raw integer but other than 
that I have no recollection.

However, I do remember struggling with the isGreaterThan and isLessThan concept 
with regard to levels as that actually implies that they are integers. Instead, 
you will see that the methods are isMoreSpecificThan and is LessSpecificThan, 
neither of which imply anything about the integers.

Ralph

> On Mar 1, 2022, at 8:23 AM, Robert Nicholson  
> wrote:
> 
> Was there any discussion in the past as to why this appears to be the reverse 
> direction in 2.x vs 1.x?
> 
> ie. OFF = Integer.MAX_VALUE in 1.x vs OFF = 0 in 2.x etc.
> 
> If I’m not mistaken I shouldn’t care about this as I’m not suppose to have 
> any dependencies on this ranking.
> 
> However, I’m still curious why it’s the opposite direction in 2.x.
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.17.2 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html.

This release contains the changes noted below:

• Over 50 improvements and fixes to the Log4j 1.x support. Continued 
testing has shown it is a suitable replacement for Log4j 1.x in most cases.
• Scripting now requires a system property be specified naming the 
languages the user wishes to allow. The scripting engine will not load if the 
property isn't set.
• By default, the only remote protocol allowed for loading 
configuration files is HTTPS. Users can specify a system property to allow 
others or prevent remote loading entirely.
• Variable resolution has been modified so that only properties defined 
as properties in the configuration file can be recursive. All other Lookups are 
now non-recursive. This addresses issues users were having resolving lookups 
specified in property definitions for use in the RoutingAppender and 
RollingFileAppender due to restrictions put in place in 2.17.1.
• Many other fixes and improvements.

Due to a break in compatibility in the SLF4J binding, Log4j now ships with two 
versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with 
SLF4J 1.7.x and earlier and log4j-slf4j18-impl should be used with SLF4J 1.8.x 
and later. SLF4J-2.0.0 alpha releases are not fully supported. See 
https://issues.apache.org/jira/browse/LOG4J2-2975 and 
https://jira.qos.ch/browse/SLF4J-511.

The Log4j 2.17.2 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.17.2

Changes in this version include:

New Features

• LOG4J2-3297: Limit loading of configuration via a url to https by 
default.
• LOG4J2-2486: Require log4j2.Script.enableLanguages to be specified to 
enable scripting for specific languages.
• LOG4J2-3303: Add TB support to FileSize. Thanks to ramananravi.
• LOG4J2-3282: Add the log4j-to-jul JDK Logging Bridge Thanks to 
Michael Vorburger.
• : Add 
org.apache.logging.log4j.core.appender.AsyncAppender.getAppenders() to more 
easily port from org.apache.log4j.AsyncAppender.getAllAppenders().
• : Add Configurator.setLevel(Logger, Level), setLevel(String, String), 
and setLevel(Class, Level). Thanks to Gary Gregory.
• LOG4J2-3341: Add shorthand syntax for properties configuration format 
for specifying a logger level and appender refs.
• LOG4J2-3391: Add optional additional fields to NoSQLAppender. Thanks 
to Gary Gregory.
Fixed Bugs

• LOG4J2-3304: Flag LogManager as initiialized if the LoggerFactory is 
provided as a property. Thanks to francis-FY.
• LOG4J2-3404: Fix DefaultConfiguration leak in PatternLayout Thanks to 
Piotr Karwasz.
• LOG4J2-3405: Document that the Spring Boot Lookup requires the 
log4j-spring-boot dependency.
• LOG4J2-3317: Fix RoutingAppender backcompat and disallow recursive 
evaluation of lookup results outside of configuration properties.
• LOG4J2-: Fix ThreadContextDataInjector initialization deadlock
• LOG4J2-3358: Fix substitutions when programmatic configuration is used
• LOG4J2-3306: OptionConverter could cause a StackOverflowError.
• : Log4j 1.2 bridge class ConsoleAppender should extend WriterAppender 
and provide better compatibility with custom appenders.
• : Log4j 1.2 bridge method NDC.inherit(Stack) should not use generics 
to provide source compatibility.
• : Log4j 1.2 bridge class PatternLayout is missing constants 
DEFAULT_CONVERSION_PATTERN and TTCC_CONVERSION_PATTERN.
• : Log4j 1.2 bridge class PropertyConfigurator should implement 
Configurator.
• : Log4j 1.2 bridge interface Configurator doConfigure() methods 
should use LoggerRepository, not LoggerContext.
• : Log4j 1.2 bridge class OptionConverter is missing 
selectAndConfigure() methods.
• : Log4j 1.2 bridge class Category should implement AppenderAttachable.
• : Log4j 1.2 bridge method Category.exists(String) should be static.
• : Log4j 1.2 bridge methods missing in org.apache.log4j.Category: 
getDefaultHierarchy(), getHierarchy(), getLoggerRepository().
• : Log4j 1.2 bridge class LogManager default constructor should be 
public.
• : Log4j 1.2 

Re: [log4j] PatternLayout %ex{filters(package,package,...)} not implemented?

[Ralph Goers]

Note that the intention of %ex has always been to include stack traces similar 
to those generated 
by the JVM and so very few options have been added to it. I would suggest that 
the doc fix is the 
better way to go.

Ralph

> On Feb 17, 2022, at 7:17 AM, Janaka Bandara  wrote:
> 
> Thanks @Volkan! I'll raise a JIRA ticket.
> 
> Also thanks @Damien for the pointer on %xEx (before starting this
> thread I did look up the mail archives but could not find your thread
> - possibly my inexperience with the filtering).
> 
> Given that the feature is already supported in
> ExtendedThrowablePatternConverter, I believe the proper "fix" here
> would be to update the documentation to point to %xEx for
> {filters(..)} syntax/usage (since filtering stack frames is actually
> not a common requirement, bringing the feature into %ex might be an
> unnecessary overhead after all). WDYT?
> 
> On 2/16/22, Volkan Yazıcı  wrote:
>> Hello Janaka & Damien,
>> 
>> This discrepancy indeed seems like a bug. Would you mind first filing a
>> JIRA ticket, please?
>> 
>> @Janaka, if you can contribute this feature in a PR that would be great! To
>> avoid redundant iterations, would you mind briefly describing how you plan
>> to address the issue in the ticket before starting to implement anything,
>> please?
>> 
>> Cheers!
>> 
>> On Mon, Feb 14, 2022 at 11:00 PM Damien Jiang 
>> wrote:
>> 
>>> I also sent a message to the mailing list about this 4 days before:
>>> https://lists.apache.org/thread/yoj9bdfqfph6q03t26r5mrdc37zjd9nw
>>> but there's been no response yet.
>>> 
>>> For now I just started using %xEx, but I'd appreciate it if this feature
>>> could be supported for %ex as well.
>>> 
>>> Thanks,
>>> Damien
>>> 
>>> On Sun, Feb 13, 2022 at 6:40 PM Janaka Bandara
>>> 
>>> wrote:
>>> 
 Hello everyone,
 
 PatternLayout (
 https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout)
 advertises this parameter syntax, to allow filtering undesired stack
 frames from logged stacktraces: `%ex{filters(package,list)}`
 
> ex|exception|throwable
> 
> {filters(package,package,...)}
> 
> Use {filters(packages)} where packages is a list of package names to
 suppress matching stack frames from stack traces.
 
 
 However on 2.17.1 (latest) when I use such a pattern:
 
 ``
 
 no filtering happens, and I still get stacktraces like:
 
 ```
 2022-02-14T07:25:23,048 ERROR TestLog error
 java.lang.IllegalStateException: Oh no
at org.p2.Foo.run(Foo.java:5)
at com.p1.Bar.run(Bar.java:7)
at org.p2.Bar.run(Bar.java:5)
at com.p1.Foo.run(Foo.java:7)
at TestLog.main(TestLog.java:11)
 ```
 
 
 Per my understanding, above config should remove the two `at
 org.p2...` frames/lines from the stacktrace.
 
 Turning off `alwaysWriteExceptions` makes no change.
 
 
 Looking at the
 
>>> `org.apache.logging.log4j.core.impl.ThrowableFormatOptions#newInstance(..)`
 codebase I see that the `filters` parameter is parsed and loaded to
 `ThrowableFormatOptions` properly; but in the actual
 
 
>>> `org.apache.logging.log4j.core.pattern.ThrowablePatternConverter#formatOption(..)`
 I cannot find any stack frame filtering logic using `filters` config.
 So to me it seems like `filters` functionality is not yet implemented
 (although I could not find any documentation/discussions to back my
 suspicion).
 
 
 I would be happy to contribute a filtering implementation honoring the
 already documented specification; however first I would like to
 confirm if I'm correct so far, or if I have missed something.
 
 TIA!
 
 --
 Janaka Bandara
 
 -
 To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-user-h...@logging.apache.org
 
 
>>> 
>> 
> 
> 
> -- 
> Janaka Bandara
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Release date for log4j 2.17.2?

[Ralph Goers]

There is no specific release date. We have a set of Jira issues that we want to 
include in the release. Once those are all resolved the release will be 
created. 

I do not anticipate it taking too much longer at this point, although I had 
hoped 
the release would have already been done by now.

Ralph

> On Feb 9, 2022, at 4:18 PM, Steve Souza  wrote:
> 
> Does anyone know the date or approximate date for the release of 2.17.2?
> 
> 
> We are trying to get rid of log4j 1.x usage in various products by using
> the log4j2 bridge. One of the products is Pentaho spoon.  The Pentaho
> vendor is working on their code to get rid of log4j 1.x dependencies, but
> they don't expect that to be until june.
> 
> To solve the problem more immediately we tried the log4j2 bridge version
> 2.17.1.  However, an exception is thrown (LogLog class not found) when
> Pentaho spoon startsup.  LogLog was added in the 2.17.2-SNAPSHOT release
> and I was able to successfully run Pentaho spoon with it!  So thanks.
> 
> However, my security team will surely ask me when the full-blown log4j
> 2.17.2 will be released before they accept this solution.
> 
> Thanks to all of you!
> 
> Info on the 2.17.2 release...
> https://issues.apache.org/jira/projects/LOG4J2/versions/12351179


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

Re: log4j RollingFileAppender filePattern issue when using the log4j Bridge

[Ralph Goers]

Log4j doesn’t perform releases on a fixed schedule. That said, we have enough 
stuff to release that one should be forthcoming very soon. Hopefully you would 
have it in a week or so.

Ralph

> On Feb 2, 2022, at 9:26 AM, Black, Cody  wrote:
> 
> 
> 
> From: Black, Cody
> Sent: Wednesday, February 2, 2022 11:21 AM
> To: log4j-user@logging.apache.org
> Cc: Yalamanchili, Sindhuja ; Datla, Subha 
> 
> Subject: log4j RollingFileAppender filePattern issue when using the log4j 
> Bridge
> 
> Hello,
> 
> We are having an issue with our RollingFileAppender where the file names are 
> being appended with dates and rolling over daily.
> 
> We were able to find a pull request that addresses these issues:
> https://github.com/apache/logging-log4j2/pull/710
> 
> Is there any sort of timeline for when changes like this are released?


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

Re: Log4j1.x Migration related to security issues

[Ralph Goers]

Thanks for these questions.

Yes, if you move to Log4j 2.17.1 and use those 3 jars then all Log4j CVEs 
(both 1.x and 2.x) will have been resolved.

How well the log4j-1.2-api works for you will depend on how many customizations 
you made around Log4j 1.x. The API has always worked well that just did their 
logging against the Log4j 1.x Logger class and didn’t customize anything. 
Recently 
we have been improving the migration support to support users who created their 
own custom components and need to use the log4j 1.x configuration files. But 
these 
enhancements would not be in 2.12.x releases

For the appropriate information you should consult the Log4j 2 websites. All 
prior 
versions of the web site are available based on the version number. For 
example, 
the migration information for 2.12.4 can be found at 
https://logging.apache.org/log4j/log4j-2.12.4/manual/migration.html.

Without knowing your application it would be impossible for me to say whether 
using 
log4j-1.2-api will be sufficient to migrate your application to Log4j 2, 
especially at older 
releases. I am afraid that you will have to test it to see.

Ralph



> On Jan 15, 2022, at 8:56 PM, 이초  wrote:
> 
> Hello
> We are currently using the log4j1.x version for the Legacy System and are
> trying to upgrade to the latest version.
> We removed the class file, which is a temporary measure, but we recommend
> upgrading it later.
> Unfortunately, if we simply change the jar file log4j1.x to log4j2.17.1,
> other old library cause problems.
> So, using the Log4j1.x bridge (log4j-1.2-api) way on the link to
> https://logging.apache.org/log4j/2.x/manual/migration.html,
> It works normally.
> If we use the bridge way like this, can we solve the security issue of
> log4j1.x and the security issue of log4j2 at once?
> There are only three log4j items on the project.
> log4j-api-2.17.1.jar
> log4j-core-2.17.1.jar
> log4j-1.2-api-2.17.1.jar
> 
> I don't think there will be a problem, but we want official answers about
> the bridge way.
> The above version is based on JDK8, and will the JDK6 and JDK7 solve this
> problem if we process the latest version released on the site the same?
> 
> We are looking forward to your answer about this problem.
> If there is no additional problem, Can I officially use the answer?
> Or is it possible to add content to the apache logging site?
> 
> I would like to hear from you about my email.
> Thank you.


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

Re: Configuring Tomcat to use log4j2 - not working, probably a trivial error in log4j2.xml

[Ralph Goers]

I haven’t checked Tomcat 9, but the log4j-appserver module was created to hook 
into Tomcat 8.5 and up. I just not sure if Tomcat changed their logging 
mechanism yet again.

Ralph

> On Jan 6, 2022, at 2:43 PM, Bruno Melloni  wrote:
> 
> A correction, after doing more troubleshooting and using even the
> original log4j2.xml (on the previous install) it seems that the old
> version was logging nothing to the files from Tomcat itself, and was
> displaying everything on the console instead... in whatever mechanism it
> wanted, so only my own apps were logging to the log4j files, with the
> Tomcat output getting lost.
> 
> So, the problem remains, it is not clear at all how you configure Tomcat
> 9 to use log4j2 after all, and none of the guides on the internet are
> complete enough to follow verbatim.
> 
> On 1/6/2022 11:37 AM, Bruno Melloni wrote:
>> A couple months ago I had no problem configuring Tomcat 9 with java 16 to 
>> use log4j2.
>> 
>> That time I simply deleted tomcat/conf/*logging.properties*, added to 
>> *tomcat/lib* the following files and it worked.
>> 
>>  * log4j-api-2.*.jar
>>  * log4j-core-2.*.jar
>>  * log4j-appserver-2.*.jar
>>  * log4j2.xml
>> 
>> Now I am setting up a new tomcat 9.0.56 with java 17 and log4j 2.17.1, 
>> followed the same steps with one difference... I tweaked the log4j2.xml to 
>> try to make it cleaner and easier to maintain/adjust.
>> 
>> Unfortunately my new setup is failing to log anything at all. The only place 
>> where I see something is on the console and it looks like it is not even 
>> log4j output as it does not match the pattern I expected.  I think I am 
>> misunderstanding something about the use of properties in a log4j2.xml file 
>> or I have some really dumb typo.
>> 
>> I hope someone can give a glance at the following and tell me where I messed 
>> up:
>> 
>> 
>>  
>>   
>> D:/work/app-j17t9-C/logs
>> > name="appsarchivedir">D:/work/app-j17t9-C/logs/archive
>> D:/work/app-j17t9-C/logs/server
>> > name="serverarchivedir">D:/work/app-j17t9-C/logs/server/archive
>> %d %-5p [%C] %m%n
>> 10 MB
>>   
>>   
>> 
>>   
>> 
>> > filePattern="${appsarchivedir}/$${date:-MM}/apps-%d{MM-dd-}-%i.log.gz">
>>  
>>   
>>   
>>
>>
>>   
>>   
>> 
>> > filePattern="${appsarchivedir}/$${date:-MM}/email-%d{MM-dd-}-%i.log.gz">
>>   
>>   
>>
>>
>>   
>>   
>> 
>> 
>> > filePattern="${serverarchivedir}/$${date:-MM}/catalina-%d{MM-dd-}-%i.log.gz">
>>   
>>   
>>
>>
>>   
>>   
>> 
>> > filePattern="${serverarchivedir}/$${date:-MM}/localhost-%d{MM-dd-}-%i.log.gz">
>>   
>>   
>>
>>
>>   
>>   
>> 
>> > filePattern="${serverarchivedir}/$${date:-MM}/manager-%d{MM-dd-}-%i.log.gz">
>>   
>>   
>>
>>
>>   
>>   
>> 
>> > fileName="${serverlogdir}/host-manager.txt" 
>> filePattern="${serverarchivedir}/$${date:-MM}/host-manager-%d{MM-dd-}-%i.log.gz">
>>   
>>   
>>
>>
>>   
>>   
>> 
>>   
>>   
>> 
>> 
>>   
>>   
>> 
>> 
>> 
>>   
>>   
>> 
>> 
>> 
>> 
>> > name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost]" 
>> level="info" additivity="false">
>>   
>> 
>> > name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]"
>>  level="info" additivity="false">
>>   
>> 
>> > name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]"
>>  level="info" additivity="false">
>>   
>> 
>>  
>>   
>> 
>>   
>> 
>> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 


-
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 external log4j2 property file

[Ralph Goers]

This is temporary and only enables log4j to debug what is going on with 
configuration, rollovers, etc. It doesn’t matter where your log4j configuration 
resides. Please set the property on whatever you use to start your server.

Ralph

> On Jan 5, 2022, at 1:34 PM, Niranjan Rao  wrote:
> 
> On 1/4/22 6:16 PM, Jin, Ying wrote:
>> Hello,
>> 
>> We have a requirement to use external server-side log4j2.properties file for 
>> our log4j2 upgrade projects. After using the following jar files in the 
>> project and use the code below to configure log4j with an external log4j2 
>> property file. We still see logging output goes to the WebLogic console 
>> instead of the application's log file.
>> 
>> If we put the log4j2.properties file in the project's classpath, the 
>> application log file can be generated on the server. However, we're required 
>> to use the external server side log4j property file.
>> 
>> log4j-api-2.17.0.jar
>> log4j-core-2.17.0.jar
>> 
>> LoggerContext context = (LoggerContext) LogManager.getContext(false);
>> context.setConfigLocation(new File(log4jConfigurationPath).toURI());
>> 
>> Please help shed some light on this. We've spent much time and efforts on 
>> this issue, but still no luck.
>> 
>> Your help is much appreciated,
>> Jenny
>> 
>> 
>> 
>> 
> We set log4j configuration in context.xml file the web application. Our log4j 
> configuration file does not even reside on the same server as same 
> configuration file is shared between multiple servers. We set the context 
> property log4jConfiguration and rest of the pieces fall in place 
> automatically.  We find this useful rather than setting system property as 
> multiple applications are running.
> 
> 
> Don't have access to code right now to see if the property is being read by 
> someone else and processed differently.
> 
> 
> Regards,
> 
> Niranjan
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 


-
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 external log4j2 property file

[Ralph Goers]

OK, what you are doing should work. Can you add -Dlog4j2.debug=true to the 
application and provide the output from the Log4j StatusLogger?

Ralph

> On Jan 5, 2022, at 8:33 AM, Jin, Ying  wrote:
> 
> Hello Ralph,
> 
> In my previous message that I mentioned that we commented out this file 
> located in our project by using "#". The log4j2.properties file on server has 
> no # sign.
> 
> Thanks,
> Jenny
> From: Jin, Ying 
> Sent: Wednesday, January 5, 2022 8:49 AM
> To: log4j-user@logging.apache.org
> Subject: RE: how to use external log4j2 property file
> 
> Ralph,
> Thanks for your reply! The two log4j jar files were put in the application's 
> WEB-INF/lib folder. Anything needs to be changed in the web.xml? One 
> application uses JDK 11, JSF2.3 and the other one uses JDK 11, GWT2.9 etc.
> Please see below for the log4j2.properties file that was put in the resource 
> folder of the application. We commented it out since we tries to use the 
> server side log4j2.properties file which has the same format and values.
> The "application.log" file can not be generated on server side. The logging 
> output only goes to the weblogic console output.
> #rootLogger.level = DEBUG
> #appenders = writeToFile, console
> 
> #monitorInterval=10
> #appenders=writeToFile, console
> 
> #appender.console.type = Console
> #appender.console.name = STDOUT
> #appender.console.layout.type = PatternLayout
> #appender.console.layout.pattern = %d %5p [%t] (%F:%L) - %m%n
> 
> #appender.writeToFile.type = RollingFile
> #appender.writeToFile.name = File
> #appender.writeToFile.fileName = /app001/applogs/application.log
> 
> #appender.writeToFile.filePattern = ${filename}.%d{-MM-dd}
> #appender.writeToFile.layout.type = PatternLayout
> #appender.writeToFile.layout.pattern = %d{-MM-dd HH:mm:ss} %c{1} [%p] %m%n
> #appender.writeToFile.policies.type = Policies
> #appender.writeToFile.policies.size.type=SizeBasedTriggeringPolicy
> #appender.writeToFile.policies.size.size=20MB
> #appender.writeToFile.strategy.type=DefaultRolloverStrategy
> #appender.writeToFile.strategy.max=10
> 
> #rootLogger.appenderRefs = writeToFile, console
> #rootLogger.appenderRef.console.ref = STDOUT
> #rootLogger.appenderRef.writeToFile.ref = File
> 
> many thanks,
> Jenny
> 
> On 2022/01/05 02:16:47 "Jin, Ying" wrote:
>> Hello,
>> 
>> We have a requirement to use external server-side log4j2.properties file for 
>> our log4j2 upgrade projects. After using the following jar files in the 
>> project and use the code below to configure log4j with an external log4j2 
>> property file. We still see logging output goes to the WebLogic console 
>> instead of the application's log file.
> 
>> 
>> If we put the log4j2.properties file in the project's classpath, the 
>> application log file can be generated on the server. However, we're required 
>> to use the external server side log4j property file.
> 
>> 
>> log4j-api-2.17.0.jar
>> log4j-core-2.17.0.jar
>> 
>> LoggerContext context = (LoggerContext) LogManager.getContext(false);
>> context.setConfigLocation(new File(log4jConfigurationPath).toURI());
>> 
>> Please help shed some light on this. We've spent much time and efforts on 
>> this issue, but still no luck.
>> 
>> Your help is much appreciated,
>> Jenny
>> 
>> 
>> 
>> 


-
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 external log4j2 property file

[Ralph Goers]

This may be a silly question, but do each of the entries actually start with #? 
 That would mean all the lines are commented out.

Ralph

> On Jan 5, 2022, at 7:49 AM, Jin, Ying  wrote:
> 
> Ralph,
> Thanks for your reply! The two log4j jar files were put in the application's 
> WEB-INF/lib folder. Anything needs to be changed in the web.xml? One 
> application uses JDK 11, JSF2.3 and the other one uses JDK 11, GWT2.9 etc.
> Please see below for the log4j2.properties file that was put in the resource 
> folder of the application. We commented it out since we tries to use the 
> server side log4j2.properties file which has the same format and values.
> The "application.log" file can not be generated on server side. The logging 
> output only goes to the weblogic console output.
> #rootLogger.level = DEBUG
> #appenders = writeToFile, console
> 
> #monitorInterval=10
> #appenders=writeToFile, console
> 
> #appender.console.type = Console
> #appender.console.name = STDOUT
> #appender.console.layout.type = PatternLayout
> #appender.console.layout.pattern = %d %5p [%t] (%F:%L) - %m%n
> 
> #appender.writeToFile.type = RollingFile
> #appender.writeToFile.name = File
> #appender.writeToFile.fileName = /app001/applogs/application.log
> 
> #appender.writeToFile.filePattern = ${filename}.%d{-MM-dd}
> #appender.writeToFile.layout.type = PatternLayout
> #appender.writeToFile.layout.pattern = %d{-MM-dd HH:mm:ss} %c{1} [%p] %m%n
> #appender.writeToFile.policies.type = Policies
> #appender.writeToFile.policies.size.type=SizeBasedTriggeringPolicy
> #appender.writeToFile.policies.size.size=20MB
> #appender.writeToFile.strategy.type=DefaultRolloverStrategy
> #appender.writeToFile.strategy.max=10
> 
> #rootLogger.appenderRefs = writeToFile, console
> #rootLogger.appenderRef.console.ref = STDOUT
> #rootLogger.appenderRef.writeToFile.ref = File
> 
> many thanks,
> Jenny
> 
> On 2022/01/05 02:16:47 "Jin, Ying" wrote:
>> Hello,
>> 
>> We have a requirement to use external server-side log4j2.properties file for 
>> our log4j2 upgrade projects. After using the following jar files in the 
>> project and use the code below to configure log4j with an external log4j2 
>> property file. We still see logging output goes to the WebLogic console 
>> instead of the application's log file.
> 
>> 
>> If we put the log4j2.properties file in the project's classpath, the 
>> application log file can be generated on the server. However, we're required 
>> to use the external server side log4j property file.
> 
>> 
>> log4j-api-2.17.0.jar
>> log4j-core-2.17.0.jar
>> 
>> LoggerContext context = (LoggerContext) LogManager.getContext(false);
>> context.setConfigLocation(new File(log4jConfigurationPath).toURI());
>> 
>> Please help shed some light on this. We've spent much time and efforts on 
>> this issue, but still no luck.
>> 
>> Your help is much appreciated,
>> Jenny
>> 
>> 
>> 
>> 


-
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 external log4j2 property file

[Ralph Goers]

Where do you have the log4j jar files? In the application, weblogics’s 
classpath, or both?

Ralph

> On Jan 4, 2022, at 7:16 PM, Jin, Ying  wrote:
> 
> Hello,
> 
> We have a requirement to use external server-side log4j2.properties file for 
> our log4j2 upgrade projects. After using the following jar files in the 
> project and use the code below to configure log4j with an external log4j2 
> property file. We still see logging output goes to the WebLogic console 
> instead of the application's log file.
> 
> If we put the log4j2.properties file in the project's classpath, the 
> application log file can be generated on the server. However, we're required 
> to use the external server side log4j property file.
> 
> log4j-api-2.17.0.jar
> log4j-core-2.17.0.jar
> 
> LoggerContext context = (LoggerContext) LogManager.getContext(false);
> context.setConfigLocation(new File(log4jConfigurationPath).toURI());
> 
> Please help shed some light on this. We've spent much time and efforts on 
> this issue, but still no luck.
> 
> Your help is much appreciated,
> Jenny
> 
> 
> 


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

Re: When was the Security issue caused?

[Ralph Goers]

Most security scanners should be following the version rules that are defined 
in the CVE. 

For all practical purposes the only versions that are CVE free are 2.3.2 
(minimum of Java 6), 2.12.4 (minimum of Java 7), and 2.17.1 (minimum of Java 
8). These were all released last week.

For other versions you would need to look at the mitigations listed in the 
Log4j security page at https://logging.apache.org/log4j/2.x/security.html. 
Depending on your configuration it is possible an upgrade might not be 
necessary but that is unlikely. For example, the most serious issue could be 
avoided if you weren’t using a PatternLayout, but almost everyone uses that.

The “feature” involved the CVE-2021-44228 was present in the very first release 
of Log4j2 in 2012.

Ralph

> On Jan 4, 2022, at 7:32 AM, John Lussmyer  wrote:
> 
> We have customers using an OLD version of our product that are now getting 
> warnings about the Log4j security issue.
> What version was that feature added in?
> (I suspect that most security scanners are just saying "Is log4j version < 
> 2.17?")
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org


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

Re: RFC5424Layout - How to format timestamp with microsecond precision

[Ralph Goers]

I think you want to set 
log4j2.clock=org.apache.logging.log4j.core.time.internal.FixedPreciseClock.

If you don’t like that implementation you can always provide your own 
implementation of PreciseClock and specify it on the system property.

I’m not sure what performance impact that Clock implementation will have.

Ralph


> On Dec 29, 2021, at 11:56 AM, Atul Pendse  wrote:
> 
> Thanks for the quick response. It took me some time to get back to this due 
> to other priorities.
> I logged a JIRA as you suggested.
> 
> Also, meanwhile, I am trying to get it working for our project by copying 
> sources and modifying them.
> I have add a new FixedDateFormat that has microsecond precision with RFC5424 
> date format. I am using the new format in Rfc5424Layout, but I came across 
> another problem.
> 
> It works fine when I run it in a standalone java app, but does not work in a 
> web app (like war deployed to tomcat).
> 
> Standalone java app uses ReusableLogEventFactory to create LogEvent. It 
> creates a MutableLogEvent, which generates actual system nano time.
> 
> In case of web app, log4j uses DefaultLogEventFactory, which creates 
> instances of Log4jLogEvent. Log4jLogEvent uses a DummyNanoClock, which always 
> defaults nano seconds to value 0. This means, events generated in a web app 
> are never going to have micro or nanosecond information.
> 
> I can override the LogEventFactory by passing system property 
> ‘-DLog4jLogEventFactory=org.apache.logging.log4j.core.impl.ReusableLogEventFactory’,
>  but I am not really sure if there are any side effects of doing that. Does 
> anyone know if it’s okay to use ReusableLogEventFactory for a web app?
> 
> Thanks,
> Atul
> 
> From: Volkan Yazıcı 
> Date: Thursday, 23 December 2021 at 2:29 PM
> To: Log4J Users List 
> Subject: Re: RFC5424Layout - How to format timestamp with microsecond 
> precision
> Hello Atul,
> 
> Your investigation of RFC5424 Layout seems to be accurate; the class
> contains a hardcoded date-time formatting working on millisecond-precision
> epoch-offset timestamps. I guess two things need to happen:
> 
>   1. A new layout configuration argument where one can override the
>   date-time format pattern.
>   2. Switching from the hardcoded date-time formatter to Log4j-provided
>   ones; FastDateFormat, FixedDateFormat, etc. I would suggest checking
>   JsonTemplateLayout's InstantFormatter – the most up-to-date one, AFAIC.
> 
> These better be placed into a JIRA ticket followed by a GitHub PR.
> 
> In the meantime, you can copy and adapt the source of Rfc5424Layout in your
> project, change the plugin name, and use it there. This can serve you until
> the feature gets implemented and shipped with a release.
> 
> Kind regards.
> 
> On Thu, Dec 23, 2021 at 9:38 AM Atul Pendse 
> wrote:
> 
>> Hi,
>> 
>> Our application sends syslog messages to a centralized facility which
>> requires timestamps to be in microsecond format.
>> Our application was so far using log4j 1.12.5’s Syslog appender to send
>> syslog messages, which used to format timestamps with microsecond precision.
>> 
>> We are now upgrading to log4j 2.17.0, and don’t see any way to get
>> microseconds included in timestamp for syslog.
>> 
>> I am trying to log messages using SyslogAppender with RFC5424 layout.
>> I see that RFC5424Layout.java restricts timestamp to millisecond precision
>> (e.g. 2021-12-22T22:54:33.889-08:00).
>> 
>> RFC5424 specification also mentions support for microsecond precision.
>> Here is some text from
>> https://datatracker.ietf.org/doc/html/rfc5424#section-6.2.3
>> 
>> Example 4
>> 
>> 2003-08-24T05:14:15.03-07:00
>> 
>>   This represents 24 August 2003 at 05:14:15am, 3 microseconds into the
>>   next second.  The microsecond resolution is indicated by the
>>   additional digits in TIME-SECFRAC.  The timestamp indicates that its
>>   local time is -7 hours from UTC.  This timestamp might be created in
>>   the US Pacific time zone during daylight savings time.
>> 
>> 
>> Is there a way to format timestamp with microsecond precision with
>> RFC5424Layout? Or is there an alternative way to get timestamp formatted
>> with microsecond precision for SyslogAppender?
>> 
>> Any help would be highly appreciated.
>> 
>> Thanks,
>> Atul Pendse
>> 


-
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.12.4 released for Java 7 (corrected links)

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.12.4 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/log4j-2.12.4/download.html.

This release contains the changes noted below:

• Address CVE-2021-44832.

This release addresses CVE-2021-44832 for users still using Java 7.

The Log4j 2.12.4 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.12.4

Changes in this version include:

Fixed Bugs

• LOG4J2-3293: JdbcAppender now uses JndiManager to access JNDI 
resources. JNDI is only enabled when system property log4j2.enableJndiJdbc is 
set to true.

Apache Log4j 2.12.4 requires a minimum of Java 7 to build and run. Log4j 2.3 
was the last release that supported Java 6.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the very implementation 
specific classes and methods. The package names and Maven groupId have been 
changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Apache Log4j 2 website:

https://logging.apache.org/log4j/2.12.4/index.html
-
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.12.4 for Java 7 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.12.4 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html.

This release contains the changes noted below:

• Address CVE-2021-44832.

This release addresses CVE-2021-44832 for users still using Java 7.

The Log4j 2.12.4 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.12.4

Changes in this version include:

Fixed Bugs

• LOG4J2-3293: JdbcAppender now uses JndiManager to access JNDI 
resources. JNDI is only enabled when system property log4j2.enableJndiJdbc is 
set to true.

Apache Log4j 2.12.4 requires a minimum of Java 7 to build and run. Log4j 2.3 
was the last release that supported Java 6.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the very implementation 
specific classes and methods. The package names and Maven groupId have been 
changed to org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Apache Log4j 2 website:

https://logging.apache.org/log4j/2.x/
-
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.12.3 for Java 7 Released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.12.3 release!

Apache log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to
Log4j that provides significant improvements over its predecessor, Log4j 1.x, 
and provides
many other modern features such as support for Markers, property substitution 
using Lookups, and asynchronous
Loggers. In addition, Log4j 2 will not lose events while reconfiguring.

The major changes contained in this release include:

* Address CVE-2021-45046 and CVE-2021-45105 by disabling recursive evaluation 
of Lookups during log event processing. Recursive evaluation is still allowed 
while generating the configuration.
* Adddress CVE-2021-44882 by preventing JNDI operations to use any protocols 
other than java.
* The JndiLookup, JndiContextSelector, and JMSAppender now require individual 
system properties to be enabled.

The JNDI components are now disabled by default and may separately be enabled 
with three individual properties; log4j2.enableJndiContextSelector, 
log4j2.enableJndiJms, and log4j2.enableJndiLookup.

GA Release 2.12.3

Changes in this version include:

New features:
o LOG4J2-2819:  Add support for specifying an SSL configuration for 
SmtpAppender.

Fixed Bugs:
o LOG4J2-3242: Rename JNDI enablement property from 'log4j2.enableJndi' to 
'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and  
'log4j2.enableJndiContextSelector'. 
o LOG4J2-3230:  Fix string substitution recursion. 


Apache Log4j 2.12.3 requires a minimum of Java 7 to build and run. It is not 
expected that any future Java 7 releases will be provided.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the
very implementation specific classes and methods. The package names and Maven 
groupId have been changed to
org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Log4j 2 website:

https://logging.apache.org/log4j/log4j-2.12.3/index.html
-
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.3.1 for Java 6 released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.3.1 release!

Apache log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to
Log4j that provides significant improvements over its predecessor, Log4j 1.x, 
and provides
many other modern features such as support for Markers, property substitution 
using Lookups, and asynchronous
Loggers. In addition, Log4j 2 will not lose events while reconfiguring.

The major changes contained in this release include:

* Address CVE-2021-45046 and CVE-2021-45105 by disabling recursive evaluation 
of Lookups during log event processing. Recursive evaluation is still allowed 
while generating the configuration.
* Adddress CVE-2021-44882 by removing processing of Lookups in the Message 
Pattern Converter of the Pattern Layout and preventing JNDI operations to use 
any protocols other than java.
* The JndiLookup, JndiContextSelector, and JMSAppender now require individual 
system properties to be enabled.

The JNDI components are now disabled by default and may separately be enabled 
with three individual properties; log4j2.enableJndiContextSelector, 
log4j2.enableJndiJms, and log4j2.enableJndiLookup.

GA Release 2.3.1

Changes in this version include:

New features:
o LOG4J2-3198:  Pattern layout no longer enables lookups within message text. 

Fixed Bugs:
o LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain disabled 
by default. Rename JNDI enablement property from 'log4j2.enableJndi' to 
'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
'log4j2.enableJndiContextSelector'. 
o LOG4J2-3230:  Fix string substitution recursion. 

Apache Log4j 2.3.1 requires a minimum of Java 6 to build and run. It is not 
expected that any future Java 6
releases will be provided.

Basic compatibility with Log4j 1.x is provided through the log4j-1.2-api 
component, however it does not implement some of the
very implementation specific classes and methods. The package names and Maven 
groupId have been changed to
org.apache.logging.log4j to avoid any conflicts with log4j 1.x.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Log4j 2 website:

https://logging.apache.org/log4j/log4j-2.3.1/index.html
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: Clarification on

[Ralph Goers]

The system property blocked lookups from being processed in what I would 
call “normal” logging - those using the style logger.info(“Hello {}”, name). 
However, 
if you made a call like logger.printf(“Hello %s”, name) lookups would not be 
blocked.

If you obtained your logger with a special LoggerFactory such as

Logger logger = LogManager.getLogger(name, new MessageFormatMessageFactory());

Then in all likelihood the resulting logging calls would not have lookups 
blocked.
So if you know that you only log using ParameterizedMessage (the kind with {}) 
then using the system property would work.

The problem is that the property is only blocking Messages that implement 
StringBuilderFormattable. ParameterizedLayout does while the printf method 
uses StringFormattedMessage which does not implement that interface.

Ralph

> On Dec 21, 2021, at 6:23 AM, David Smiley  wrote:
> 
> Hello,
> 
> I'm on the Apache Solr PMC, and I'm trying to do some due diligence on
> understanding the extent to which "log4j2.formatMsgNoLookups" may or may
> not be effective in mitigating certain vulnerabilities *for Solr*.  Solr
> recently upgraded to Log4j 2.16 but I want to validate the extent to which
> this mitigation measure is appropriate for older versions of Solr.  Log4j's
> news page[1] has the following text:
> 
> *Older (discredited) mitigation measures*
>> 
>> This page previously mentioned other mitigation measures, but we
>> discovered that these measures only limit exposure while leaving some
>> attack vectors open.
>> 
> Other insufficient mitigation measures are: setting system property
>> log4j2.formatMsgNoLookups or environment variable
>> LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the
>> logging configuration to disable message lookups with %m{nolookups},
>> %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
>> 
>> The reason these measures are insufficient is that, in addition to the
>> Thread Context attack vector mentioned above, there are still code paths in
>> Log4j where message lookups could occur: known examples are applications
>> that use Logger.printf("%s", userInput), or applications that use a custom
>> message factory, where the resulting messages do not implement
>> StringBuilderFormattable. There may be other attack vectors.
>> 
> [1]: https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> 
> The use of the word "discredited" is suggestive that this
> log4j2.formatMsgNoLookups setting will be of no use to anyone.  My
> suspicion is that it can be, but is dependent on the extent to which the
> application (Solr + Slf4j) actually uses Log4j2.  It is worth spending time
> understanding this (instead of throwing up your hands and saying, just
> upgrade) because upgrading is quite a hassle for many users.  Many users of
> Log4j only use Log4j via Slf4j which is comparatively easier to audit.
> Solr is not quite in this camp; it injects a custom appender in order to
> render messages on it's logging UI.
> 
> Taking a specific example here given in the news page: Logger.printf.  I'm
> not seeing the problem; can someone offer me a pointer?  I've checked out a
> version of Solr that uses Log4j 2.14.1 and set the system property, and
> crafted up some trivial unit test that calls Logger.printf with the intent
> of exploring what happens internally that is concerning.  I do see the
> problem in MessagePatternConverter that is averted by the system property.
> 
> Feel free to reach me directly if there are sensitivities to a response.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley


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

Re: [ANNOUNCEMENT] Apache Log4j 2.17.0 Released

[Ralph Goers]

Not a problem. Glad your problem was fixed.

Ralph

> On Dec 18, 2021, at 2:12 PM, jmiguel rodriguez  
> wrote:
> 
> El sáb, 18 dic 2021 a las 22:01, jmiguel rodriguez (<
> jmiguel.rodrig...@gmail.com>) escribió:
> 
>> 
>> Hi guys,
>> 
>> First message here, so first of all, THANK YOU VERY MUCH to the team. You
>> really deserve a big present this christmas!
>> 
>> El sáb, 18 dic 2021 a las 18:12, Ralph Goers ()
>> escribió:
>> 
>>> The Apache Log4j 2 team is pleased to announce the Log4j 2.17.0 release!
>>> 
>> 
>> And now my question: in a multimodule project I'm working in I've just
>> tried to upgrade to 2.17.0. In about 25 modules there's just one that
>> doesn't compile:
>> 
>> Could not get unknown property 'log4j2Version' for object of type
>> org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler
>> 
> 
> Sorry guys. I'm an (also tired on Saturday) idiot. My fault, a bad declared
> variable across the projects.  All looks good
> 
> Sorry again.
> 
> 
> 
> 
> -- 
> saludos,
> jmiguel
> 
> Twitter: @jmiguel <http://www.twitter.com/jmiguel>
> https://www.jmiguel.eu


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

Re: [ANNOUNCEMENT] Apache Log4j 2.17.0 Released

[Ralph Goers]

I’m not going to be a lot of help on this as I don’t use Gradle.

The only thing I can think of that could be affecting this is that the 
log4j-api pom.xml file was declaring a dependency 
on the zip file generated by the log4j-api-java9 module. It had “provided” 
scope meaning it should more or less be 
ignored since the system already would have it.  However, it was found that the 
Maven enforcer plugin was having 
problems with that since we don’t publish that artifact as part of the release 
as it is only used in the build process. 
It turned out the dependency wasn’t actually needed for the build so it was 
removed in 2.17.0.

Log4j-core had the same issue as it also had classes being compiled 
specifically for Java 9+.

Why that would cause problems with Gradle though I can’t say. You might check 
to see if there is something looking 
for log4j-api-java9 and/or log4j-core-java9.

Ralph

> On Dec 18, 2021, at 2:01 PM, jmiguel rodriguez  
> wrote:
> 
> Hi guys,
> 
> First message here, so first of all, THANK YOU VERY MUCH to the team. You
> really deserve a big present this christmas!
> 
> El sáb, 18 dic 2021 a las 18:12, Ralph Goers ()
> escribió:
> 
>> The Apache Log4j 2 team is pleased to announce the Log4j 2.17.0 release!
>> 
> 
> And now my question: in a multimodule project I'm working in I've just
> tried to upgrade to 2.17.0. In about 25 modules there's just one that
> doesn't compile:
> 
> Could not get unknown property 'log4j2Version' for object of type
> org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler
> 
> Relevant trace :
> 
> A problem occurred evaluating project ':x'.
>> Could not get unknown property 'log4j2Version' for object of type
> org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
> * Try:
>> Run with --info or --debug option to get more log output.
>> Run with --scan to get full insights.
> * Exception is:
> org.gradle.api.GradleScriptException: A problem occurred evaluating project
> ':screener-api'.
> at
> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:93)
> at
> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.lambda$apply$0(DefaultScriptPluginFactory.java:133)
> at
> org.gradle.configuration.ProjectScriptTarget.addConfiguration(ProjectScriptTarget.java:79)
> at
> org.gradle.configuration.DefaultScriptPluginFactory$ScriptPluginImpl.apply(DefaultScriptPluginFactory.java:136)
> at
> org.gradle.configuration.BuildOperationScriptPlugin$1.run(BuildOperationScriptPlugin.java:65)
> 
> [...]
> 
> Caused by: groovy.lang.MissingPropertyException: Could not get unknown
> property 'log4j2Version' for object of type
> org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
> at
> org.gradle.internal.metaobject.AbstractDynamicObject.getMissingProperty(AbstractDynamicObject.java:88)
> at
> org.gradle.internal.metaobject.ConfigureDelegate.getProperty(ConfigureDelegate.java:130)
> at
> build_e3ba1ynsfxxz4aoghafb89nxl$_run_closure5.doCall(/builds/-C27SRoJ/17/product/backend/backend/src/screener-api/build.gradle:127)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.gradle.util.internal.ClosureBackedAction.execute(ClosureBackedAction.java:72)
> at
> org.gradle.util.internal.ConfigureUtil.configureTarget(ConfigureUtil.java:155)
> at org.gradle.util.internal.ConfigureUtil.configure(ConfigureUtil.java:106)
> at
> org.gradle.api.internal.project.DefaultProject.dependencies(DefaultProject.java:1237)
> at jdk.internal.reflect.GeneratedMethodAccessor136.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:484)
> at
> org.gradle.internal.metaobject.BeanDynamicObject.tryInvokeMethod(BeanDynamicObject.java:196)
> at
> org.gradle.internal.metaobject.CompositeDynamicObject.tryInvokeMethod(CompositeDynamicObject.java:98)
> at
> org.gradle.internal.extensibility.MixInClosurePropertiesAsMethodsDynamicObject.tryInvokeMethod(MixInClosurePropertiesAsMethodsDynamicObject.java:34)
> at
> org.gradle.groovy.scripts.BasicScript$ScriptDynamicObject.tryInvokeMethod(BasicScript.java:135)
> at
> org.gradle.internal.metaobject.AbstractDynamicObject.invokeMethod(AbstractDynamicObject.java:163)
> at org.gradle.groovy.scripts.BasicScript.invokeMethod(Ba

[ANNOUNCEMENT] Apache Log4j 2.17.0 Released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.17.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html.

The major changes contained in this release include:

• Address CVE-2021-45105 by disabling recursive evaluation of Lookups 
during log event processing. Recursive evaluation is still allowed while 
generating the configuration.
• The JndiLookup, JndiContextSelector, and JMSAppender now require 
individual system properties to be enabled.
• Remove LDAP and LDAPS as supported protocols from JNDI.

The single log4j2.enableJndi property introduced in Log4j 2.16.0 has been 
replaced with three individual properties; log4j2.enableJndiContextSelector, 
log4j2.enableJndiJms, and log4j2.enableJndiLookup.

The Log4j 2.17.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.17.0

Changes in this version include:

Fixed Bugs

• LOG4J2-3230: Fix string substitution recursion.
• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will remain 
disabled by default. Rename JNDI enablement property from 'log4j2.enableJndi' 
to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms', and 
'log4j2.enableJndiContextSelector'.
• LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9 as 
dependencies as it causes problems with the Maven enforcer plugin.
• LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE when 
parsing properties file filters.
• LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to port 
512 instead of 514.
• LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol to 
TCP.

Apache Log4j 2.17.0 requires a minimum of Java 8 to build and run. Log4j 2.12.2 
is the last release to support Java 7. Java 7 is not longer supported by the 
Log4j team.

For complete information on Apache Log4j 2, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Apache Log4j 2 website: https://logging.apache.org/log4j/2.x/index.html.


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

Re: Potential Bug in Log4j2?

[Ralph Goers]

Please create a Jira issue for this with as much information as you can.

Thanks,
Ralph

> On Dec 16, 2021, at 5:01 PM, Bhavesh Patel  
> wrote:
> 
> Hi Matt/Anyone,   Any solution for this?
> Regards,Bhavesh.
>On Thursday, December 16, 2021, 01:57:23 PM PST, Bhavesh Patel 
>  wrote:  
> 
>  HI,As a part of this commit, 
> https://github.com/apache/logging-log4j2/commit/97db5743a3b10e9017bf70794d6275b21553dd44,
>  the thread leak issue was fixed. But did it introduce a bug?What if the 
> KafkaAppender is stopped? In the calls hierarchy, the KafkaManager.stop() is 
> called. This in turn calls KakfaManager.releaseSub() which calls 
> KafakManager.closeProducer(). The closeProducer() closes the producer. Now 
> when you try to start the KafkaAppender and append a message using 
> KafkaAppender.append() the following message is seen
> "Cannot perform operation after producer has been closed".
> Please let me know if you see this as a bug.
> Regards,Bhavesh.
> 
> 
> 
> 
> 
> 
> 


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

Re: [ANNOUNCEMENT] Apache Log4j 2.15.0 Released

[Ralph Goers]

The setting does not affect lookups that are specified in the Log4j 
configuration file. Only lookups that are specified in the message being logged.

Ralph

> On Dec 10, 2021, at 2:45 PM, Niranjan Rao  wrote:
> 
> Hello,
> 
> It's not entirely clear to me if setting formatMsgNoLookups=true affects only 
> messages that are getting logged or does it affect appenders declared using 
> similar syntax.
> 
> Taking example from log4j appender documentation, will affect any $ entries 
> declared here?
> 
>name="Rolling-${mdc:UserId}"
>   fileName="${mdc:UserId}.log"
>   filePattern="${mdc:UserId}.%i.log.gz">
> .
> 
> 
> I tried to lookup documentation of the variable, but unfortunately failed.
> 
> Regards,
> 
> Niranjan
> 
> On 12/10/21 2:08 AM, Ralph Goers wrote:
>> The Apache Log4j 2 team is pleased to announce the Log4j 2.15.0 release!
>> 
>> Apache Log4j is a well known framework for logging application behavior. 
>> Log4j 2 is an upgrade to Log4j that provides significant improvements over 
>> its predecessor, Log4j 1.x, and provides many other modern features such as 
>> support for Markers, lambda expressions for lazy logging, property 
>> substitution using Lookups, multiple patterns on a PatternLayout and 
>> asynchronous Loggers. Another notable Log4j 2 feature is the ability to be 
>> "garbage-free" (avoid allocating temporary objects) while logging. In 
>> addition, Log4j 2 will not lose events while reconfiguring.
>> 
>> The artifacts may be downloaded from 
>> https://logging.apache.org/log4j/2.x/download.html 
>> <https://logging.apache.org/log4j/2.x/download.html> 
>> <https://logging.apache.org/log4j/2.x/download.html 
>> <https://logging.apache.org/log4j/2.x/download.html>> 
>> <https://logging.apache.org/log4j/2.x/download.html 
>> <https://logging.apache.org/log4j/2.x/download.html> 
>> <https://logging.apache.org/log4j/2.x/download.html 
>> <https://logging.apache.org/log4j/2.x/download.html>>>.
>> 
>> This release contains a number of bug fixes and minor enhancements which are 
>> listed below.
>> 
>> The Log4j team has been made aware of a security vulnerability, 
>> CVE-2021-44228, that has been addressed in Log4j 2.15.0.
>> 
>> Log4j’s JNDI support has not restricted what names could be resolved. Some 
>> protocols are unsafe or can allow remote code execution. Log4j now limits 
>> the protocols by default to only java, ldap, and ldaps and limits the ldap 
>> protocols to only accessing Java primitive objects by default served on the 
>> local host.
>> 
>> One vector that allowed exposure to this vulnerability was Log4j’s allowance 
>> of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now 
>> disabled by default. While an option has been provided to enable Lookups in 
>> this fashion, users are strongly discouraged from enabling it.
>> 
>> Users who cannot upgrade to 2.15.0 can mitigate the exposure by:
>> 
>> a) Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as 
>> a command line option or add log4j.formatMsgNoLookups=true to a 
>> log4j2.component.properties file on the classpath to prevent lookups in log 
>> event messages.
>> b) Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout 
>> configuration to prevent lookups in log event messages.
>> c) Remove the JndiLookup and JndiManager classes from the log4j-core jar. 
>> Removal of the JndiManager will cause the JndiContextSelector and 
>> JMSAppender to no longer function.
>> 
>> Due to a break in compatibility in the SLF4J binding, Log4j now ships with 
>> two versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used 
>> with SLF4J 1.7.x and earlier and log4j-slf4j18-impl should be used with 
>> SLF4J 1.8.x and later. SLF4J-2.0.0 alpha releases are not fully supported. 
>> See https://issues.apache.org/jira/browse/LOG4J2-2975 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975> 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975>> 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975> 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975 
>> <https://issues.apache.org/jira/browse/LOG4J2-2975>>> and 
>> https://jira.qos.ch/browse/SLF4J-511 <https://jira.qos.ch/browse/SLF4J-511> 
>> <https://jira.qos.ch/browse/S

[ANNOUNCEMENT] Apache Log4j 2.15.0 Released

[Ralph Goers]

The Apache Log4j 2 team is pleased to announce the Log4j 2.15.0 release!

Apache Log4j is a well known framework for logging application behavior. Log4j 
2 is an upgrade to Log4j that provides significant improvements over its 
predecessor, Log4j 1.x, and provides many other modern features such as support 
for Markers, lambda expressions for lazy logging, property substitution using 
Lookups, multiple patterns on a PatternLayout and asynchronous Loggers. Another 
notable Log4j 2 feature is the ability to be "garbage-free" (avoid allocating 
temporary objects) while logging. In addition, Log4j 2 will not lose events 
while reconfiguring.

The artifacts may be downloaded from 
https://logging.apache.org/log4j/2.x/download.html 
 
>.

This release contains a number of bug fixes and minor enhancements which are 
listed below.

The Log4j team has been made aware of a security vulnerability, CVE-2021-44228, 
that has been addressed in Log4j 2.15.0.

Log4j’s JNDI support has not restricted what names could be resolved. Some 
protocols are unsafe or can allow remote code execution. Log4j now limits the 
protocols by default to only java, ldap, and ldaps and limits the ldap 
protocols to only accessing Java primitive objects by default served on the 
local host.

One vector that allowed exposure to this vulnerability was Log4j’s allowance of 
Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now 
disabled by default. While an option has been provided to enable Lookups in 
this fashion, users are strongly discouraged from enabling it.

Users who cannot upgrade to 2.15.0 can mitigate the exposure by:

a) Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a 
command line option or add log4j.formatMsgNoLookups=true to a 
log4j2.component.properties file on the classpath to prevent lookups in log 
event messages.
b) Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout 
configuration to prevent lookups in log event messages.
c) Remove the JndiLookup and JndiManager classes from the log4j-core jar. 
Removal of the JndiManager will cause the JndiContextSelector and JMSAppender 
to no longer function.

Due to a break in compatibility in the SLF4J binding, Log4j now ships with two 
versions of the SLF4J to Log4j adapters. log4j-slf4j-impl should be used with 
SLF4J 1.7.x and earlier and log4j-slf4j18-impl should be used with SLF4J 1.8.x 
and later. SLF4J-2.0.0 alpha releases are not fully supported. See 
https://issues.apache.org/jira/browse/LOG4J2-2975 
 
> and 
https://jira.qos.ch/browse/SLF4J-511  
>.

Some of the new features in Log4j 2.15.0 include:

• Support for Arbiters, which are conditionals that can enable sections 
of the logging configuration for inclusion or exclusion. In particular, 
SpringProfile, SystemProperty, Script, and Class Arbiters have been provided 
that use the Spring profile, System property, the result of a script, or the 
presence of a class respectively to determine whether a section of 
configuration should be included.
• Support for Jakarta EE 9. This is functionally equivalent to Log4j's 
log4j-web module but uses the Jakarta project.
• Various performance improvements.

Key changes to note:

• Prior to this release Log4j would automatically resolve Lookups 
contained in the message or its parameters in the Pattern Layout. This behavior 
is no longer the default and must be enabled by specifying %msg{lookup}.
• The JNDI Lookup has been restricted to only support the java, ldap, 
and ldaps protocols by default. LDAP also no longer supports classes that 
implement the Referenceable interface and restricts the Serializable classes to 
the Java primative classes by default and requires an allow list to be 
specified to access remote LDAP servers.
The Log4j 2.15.0 API, as well as many core components, maintains binary 
compatibility with previous releases.

GA Release 2.15.0

Changes in this version include:

New Features

• LOG4J2-3198: Pattern layout no longer enables lookups within message 
text by default for cleaner API boundaries and reduced formatting overhead. The 
old 'log4j2.formatMsgNoLookups' which enabled this behavior has been removed as 
well as the 'nolookups' message pattern converter option. The old behavior can 
be enabled on a per-pattern basis using '%m{lookups}'.
• LOG4J2-3194: Allow fractional attributes for size attribute of 
SizeBsaedTriggeringPolicy. Thanks to markuss.
• LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty 

Re: Web application name.

[Ralph Goers]

This is a problematic question. Frequently the name of the web application is 
considered 
to be the name of the War file it exists in. AFAIK there is no way to get that. 
The data in 
the servlet context may, or may not, represent the application name.

A spring boot application on the other hand, gets its name from the value of 
the spring.application.name 
property.

The answer to this question really depends on what you consider to be the web 
application 
name and where it comes from.

Ralph

> On Nov 23, 2021, at 12:13 PM, Volkan Yazıcı  wrote:
> 
> Would web:servletContextName lookup
>  work
> for you?
> 
> On Tue, Nov 23, 2021 at 3:46 PM vahid ghasemi 
> wrote:
> 
>> Hello guys.
>> How can I log my web application name?
>> 



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

Re: authapi.jar with Log4j2

[Ralph Goers]

It appears that this is from a proprietary product so I don’t have access to 
their source 
code. You only have a couple of options:
1. Decompile the AgentDebugger class and the portion of AuthSessionFactory that 
calls 
it and provide that to us so we can identify why it needs this. However, that 
might violate 
whatever license agreement you have with RSA.
2. Contact RSA and report this issue.

I can’t be sure but it almost looks like RSA has implemented their own Log4j 
1.x implementation. 
If that indeed is the case then there is no way a Log4j 2 compatibility layer 
is going to support that.

Ralph

> On Nov 10, 2021, at 6:49 AM, EDMONDO SENA  wrote:
> 
> In log4j2 the LocationInfo where is it?
> 
> The exception is:
> 
> at com.rsa.authagent.authapi.logger.AgentDebugger.formatLocationMsg
> at com.rsa.authagent.authapi.logger.AgentDebugger.log
> at com.rsa.authagent.authapi.logger.AgentDebugger.trace
> at com.rsa.authagent.authapi.AuthSessionFactory.a
> at com.rsa.authagent.authapi.AuthSessionFactory.
> at com.rsa.authagent.authapi.AuthSessionFactory.getInstance()
> ..
> at ..common.library.rsa.RSAConnection.
> at ..common.library.rsa.RSAConnection.getInstance(RSAConnection.java)
> 
> 
> Thanks.
> //Edmondo.
> 
> 
> 
> 
> Il giorno gio 4 nov 2021 alle ore 08:33 Ralph Goers <
> ralph.go...@dslextreme.com> ha scritto:
> 
>> You are correct that there is no LocationInfo constructor. Unfortunately,
>> we can’t really help here without more information.
>> 
>> 1. I am assuming this is Auth0’s AuthAPI?  I don’t even see them reference
>> any logging framework.
>> 2. If it is brought in by a dependency we would need to see the stack
>> trace to determine what is doing it to help you fix it.
>> 3. We would need the stack trace to figure out what the caller is doing
>> and why they need the LocationInfo.
>> 
>> So without the stack trace we don’t have any info to determine what the
>> problem is.
>> 
>> Ralph
>> 
>>> On Nov 3, 2021, at 1:20 AM, EDMONDO SENA  wrote:
>>> 
>>> Specifically, the LocationInfo constructor that is called by the 3pp lib
>> does not exist in the new library.
>>> 
>>> 
>>> 
>>> 
>>> Il giorno ven 29 ott 2021 alle ore 17:43 Gary Gregory <
>> garydgreg...@gmail.com <mailto:garydgreg...@gmail.com>> ha scritto:
>>> What is the complete stack trace?
>>> 
>>> Gary
>>> 
>>> On Fri, Oct 29, 2021, 11:37 EDMONDO SENA > edse...@gmail.com>> wrote:
>>> 
>>>> There are no log4j1 jars in classpath.
>>>> 
>>>> //Edmondo.
>>>> 
>>>> 
>>>> 
>>>> Il giorno ven 29 ott 2021 alle 17:34 Doug Wegscheid <
>>>> dwegsch...@sbcglobal.net <mailto:dwegsch...@sbcglobal.net>> ha
>> scritto:
>>>> 
>>>>> ...and make sure that the log4j v1 jar files are NOT on the
>> classpath.
>>>>> 
>>>>>On Friday, October 29, 2021, 11:21:52 AM EDT, Gary Gregory <
>>>>> garydgreg...@gmail.com <mailto:garydgreg...@gmail.com>> wrote:
>>>>> 
>>>>> Make sure the log4j 2 jars are first on the class path and do not
>>>> include
>>>>> any log4j 1 jars.
>>>>> 
>>>>> Gary
>>>>> 
>>>>> On Fri, Oct 29, 2021, 11:18 EDMONDO SENA > edse...@gmail.com>> wrote:
>>>>> 
>>>>>> 
>>>>>> it has already been done and it doesn't work!
>>>>>> 
>>>>>> This is the exception:
>>>>>> 
>>>>>> Exception in thread "main"
>>>>>> 
>> Java.lang.NoSuchMethodError:org.apache.log4j.spi.LocationInfo.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2021/10/29 15:09:59, Doug Wegscheid > <mailto:dwegsch...@sbcglobal.net>>
>>>> wrote:
>>>>>>> Put the log4j-1.2-api.jar on the classpath along with the other
>>>>>> necessary log4j2 jars, and configure log4j2.
>>>>>>> 
>>>>>>> Sent from AT Yahoo Mail on Android
>>>>>>> 
>>>>>>> On Fri, Oct 29, 2021 at 11:07 AM, EDMONDO SENA<
>> edse...@gmail.com <mailto:edse...@gmail.com>>
>>>>>> wrote:  it's not that simple one, a thing is to write, one thing
>> is to
>>>>>> understand what to do! Said so it seems a simplistic discu

Re: Temporarily store/restore the current configuration

[Ralph Goers]

Sorry for not replying sooner but yes, that was going to be my response. Once 
stopped a Configuration cannot be restarted. 

I have wanted to be able to provide an easy way to clone a configuration but 
have never gotten around to it. This would be useful if you have modified the c
onfiguration after it initialized 

We have also discussed having the configuration be able to serialize itself 
back 
into a configuration file but again, no one has attempted to do it.

Ralph

> On Nov 9, 2021, at 5:15 AM, Dawid Weiss  wrote:
> 
> So I took a closer look and even found another place in my code where
> I previously had the same problem... setConfiguration() won't work in
> my
> example code - ever. Seems like Configuration objects are not meant to
> be reused at all. They have an internal state (lifecycle) and, once
> stopped, they're effectively unusable. So, when you try to do this:
> 
> var ctx = (LoggerContext) LogManager.getContext(false);
> var current = ctx.getConfiguration();
> try {
>  ctx.setConfiguration(myQuietConfiguration);
>  otherCode();
> } finally {
>  ctx.setConfiguration(current);
> }
> 
> what happens is the "current" configuration is stopped and internally
> will never reinitialize all the appenders (and internals) again.
> Here's why:
> 
> https://github.com/apache/logging-log4j2/blob/0043e9238af0efd9dbce462463e0fa1bf14e35b0/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java#L290-L292
> 
> The initialization routine calls doConfigure which in turn does all
> the tricky stuff adding appenders, etc. I'm not sure whether this is
> intentional or not but if Configuration objects are not meant for
> reuse then I'd throw an exception if they're in illegal state (in
> ctx.setConfiguration)... this would make it much easier to figure out.
> And if there should be a way to reuse them then I think it's a bug
> somewhere because it currently doesn't work (even on the simplest of
> examples).
> 
> Incidentally, you can reinitialize the configuration from scratch -
> then everything works like a charm, no need to call updateLoggers
> (it's done internally):
> 
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> URI previousConfiguration = ctx.getConfigLocation();
> ctx.setConfigLocation(newConfigLocation);
> try {
>  otherCode();
> } finally {
>  ctx.setConfigLocation(previousConfiguration);
> }
> 
> Of course it requires re-parsing the configuration multiple times so
> is not ideal.
> 
> I'd love to hear from the developers about what they think in terms of
> the Configuration object reuse/ lifecycle.
> 
> Dawid
> 
> 
> On Tue, Nov 9, 2021 at 10:30 AM Dawid Weiss  wrote:
>> 
>> 
>> Hi Chris!
>> 
>> Small world, eh? :)
>> 
>>> Dawid: The piece you're missing is LoggerContext.updateLoggers(...)
>> 
>> 
>> I did that too... I think. I have dynamic appender redirection (teeing) in 
>> another place - this is where updateLoggers() is used. But this time I 
>> wanted to swap out entire configurations (this may involve different logger 
>> setup, appenders, etc.) and could't make it work properly, no matter what. 
>> I'll go back to the drawing board and retry.
>> 
>> I do understand it's not a typical use-case but it's actually a fairly 
>> frequent thing that happens in integration tests when you don't want to see 
>> stuff
>> that is tested (well, maybe you do, but only if something fails).
>> 
>> Dawid
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 



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

Re: downsides/overhead of stashing & restoring (probably empty) ThreadContextMap ?

[Ralph Goers]

> On Nov 8, 2021, at 3:04 PM, Chris Hostetter  wrote:
> 
> 
> And if the ThreadContext is _not_ empty? ... is there anything about how 
> it's implemented that would make the initial map copy (and later 
> `putAll(...)` call) more "epensive" from a performance standpoint then an 
> off the shelf 'new HashMap?

Well, the cost is going to be dependent on how many items are in the Map. 
But, as I said, the reason nobody does this is because the Map is always 
empty unless you have another filter in front of it putting stuff in, in which 
case you have a bigger problem because your filter is ignoring what it is 
adding.

Your app should know what filters is using and what they do. The container 
is never going to add stuff to the ThreadContext. That is why it passes you 
an HttpRequest and you have a ServletContext. So it doesn’t need to put 
anything in the ThreadContext. But you very well may want to pull stuff out 
of those and add them to the ThreadContext so you don’t have to pass the 
HttpRequest to everything.

The bottom line is that you are being a good citizen by clearing the Map.

Ralph





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

Re: Providing library defaults

[Ralph Goers]

I’m not sure I completely understand the question 
* I’m not sure what you mean by “additive default configuration”. Certainly you 
can have a default configuration. Use you can add to it.
* Don’t log by default would mean that both onMatch and onMismatch are set to 
DENY

Ralph

> On Oct 29, 2021, at 3:20 PM, Marius Volkhart  wrote:
> 
> Hello all,
> 
> I’m authoring a library that uses the Log4j API for internal logging. I want 
> to provide my users valuable logging, but only under some circumstances. For 
> example, if an expensive initializer gets called frequently, log a message 
> indicating a possible performance impact. Or if logging something that may 
> contain sensitive data, only logging it if they opt-in.
> 
> I would typically solve this at the application layer using Filters. A 
> ThresholdFilter and a MarkerFilter for example. Is there a way to provide an 
> additive default configuration for my users? Or some other mechanism for 
> saying “don’t log by default”? Or perhaps differently, am I wrong for 
> thinking about the problem/solution this way?
> 
> Thanks in advance!
> 
> 
> Cheers,
> Marius 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 



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

Re: Log4j2 configuration format with best coverage

[Ralph Goers]

This deserves a really long answer that I should add to my blog site. I’ll post 
a shorter answer on stackoverflow.

Ralph

> On Oct 25, 2021, at 4:07 AM, Stamatis Zampetakis  wrote:
> 
> Hi all,
> 
> I posted the following question on stackoverflow a few days ago [1]. Any
> feedback is much appreciated.
> 
> Log4j2 currently supports 4 configuration formats: XML, JSON, YAML, and
> properties syntax. I couldn't find in the documentation if all the formats
> are exactly equivalent in terms of feature coverage.
> 
> Is it possible to use all features of Log4j2 in every format or are there
> certain formats that lack some expressiveness?
> 
> I vaguely remember in the past that I had some trouble setting up a feature
> in the property syntax while it was working in the XML syntax; it could be
> my lack of knowledge at the time instead of a missing feature but if
> somebody can provide a reference about equivalence or not it would be
> helpful.
> 
> Best,
> Stamatis
> 
> [1]
> https://stackoverflow.com/questions/69659109/log4j2-configuration-format-with-best-coverage



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

Re: DirectWriteRolloverStrategy - how to remove old logs?

[Ralph Goers]

You need to configure a Delete Action. Search for Delete on Rollover in 
http://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender 
.

Ralph

> On Oct 11, 2021, at 7:05 AM, Alan Franzoni  wrote:
> 
> Hello, I'm using log4j 2.14.1.
> 
> What I'd like to do is to have an appender which lets me have one log file
> per day, but then delete older logs after N days (e.g. I'd like to have at
> most 10 logfiles, one per day).
> 
> I've tried using the DirectWriteRolloverStrategy, which seems good and
> creates one log file per day when properly configured, but apparently has
> no way of deleting older files, so my log directory gets filled with logs;
> the maxFiles attribute only seems to set ```The maximum number of files to
> allow in the time period matching the file pattern``` (see
> https://logging.apache.org/log4j/2.x/manual/appenders.html) - so, it's only
> useful when there's a size-based policy that rotates logs further.
> 
> The Delete Action only appears to work with the DefaultRolloverStrategy.
> 
> My appender configuration:
> ```
> appender.rolling.type = RollingFile
> appender.rolling.name = ROLLING
> appender.rolling.filePattern = /var/log/application-%d{-MM-dd}.log
> appender.rolling.layout.type = PatternLayout
> appender.rolling.layout.pattern =
> [%d{-MM-dd'T'HH:mm:ss,SSS}{UTC}Z][%p][%C:%L] %m%n
> appender.rolling.policies.type = Policies
> appender.rolling.policies.time.type = TimeBasedTriggeringPolicy
> appender.rolling.strategy.type = DirectWriteRolloverStrategy
> appender.rolling.strategy.maxFiles = 10
> ```
> 
> Is there any way to configure the maximum amount (or maximum age) of logs
> in that directory, (ideally) using properties (but if XML is fine if
> properties don't work for this use case) ?
> 
> Thanks,
> 
> Alan

Re: Is there a way to develop my own resolver for JSON template layout?

[Ralph Goers]

Volkan,

The syntax is wrong for it to be a lookup. With that syntax it must be a 
PatternConverter.  
You can find the source for it at 
https://github.com/apache/skywalking-java/blob/main/apm-application-toolkit/apm-toolkit-log4j-2.x/src/main/java/org/apache/skywalking/apm/toolkit/log/log4j/v2/x/TraceIdConverter.java,
 
not that looking at will help you figure out what it actually does.

His request makes sense though. He wants the traceId to show up as an 
individual 
field in the JSON. It would have been better though if SkyWalking had provided 
a 
simple way to inject it into the ThreadContextMap. Then nothing special would 
be needed.

Ralph

> On Sep 19, 2021, at 12:24 PM, Volkan Yazıcı  wrote:
> 
> This is the first time I have ever heard about SkyWalking, hence apologies
> in advance if I am about to say something nonsense. In the link you have
> shared, I see that you use the `%traceId` directive in your PatternLayout
> configuration. Is that a simple Lookup implementation, e.g., extending from
> StrLookup? If so, why not simply use that Lookup in JsonTemplateLayout
> 
> too?
> 
> On Sat, Sep 18, 2021 at 10:26 AM jingguo yao  wrote:
> 
>> Volkan, I am thinking of the integration of Log4j2 JSON template layout
>> with SkyWalking. SkyWalking has done the integration with Log4j2 for the
>> pattern layout:
>> 
>> https://github.com/apache/skywalking-java/blob/main/docs/en/setup/service-agent/java-agent/Application-toolkit-log4j-2.x.md
>> .
>> With the resolver extending supported, it can be easily done.
>> 
>> 
>> 
>> On Fri, Sep 17, 2021 at 3:26 PM Volkan Yazıcı 
>> wrote:
>> 
>>> Jingguo, I am curious, what kind of a new resolver do you want to
>> develop?
>>> If that is something useful for other users, it is good to ship that in
>>> Log4j by default.
>>> 
>>> On Mon, Sep 6, 2021 at 8:03 AM jingguo yao  wrote:
>>> 
 
 
>>> 
>> https://logging.apache.org/log4j/2.x/manual/json-template-layout.html#map-resolver-template
 lists all the supported resolvers. I want to develop a new resolver. Is
 there a way to do this?
 
 --
 Jingguo
 
>>> 
>> 
>> 
>> --
>> Jingguo
>> 



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

Re: Loggers with same name - how to work around?

[Ralph Goers]

Actually Matt, I don’t believe the routing appender will help for what he is 
asking for. Sorry to be blunt but it really makes no sense.

Log events get generated by an application and are routed to the appropriate 
LoggerConfig by way of a Logger. The LoggerConfig then routes them to the 
appropriate Appender(s).  The main difference between a “normal” LoggerConfig 
and an AsyncLoggerConfig is, of course, that one is synchronous and one is 
asynchronous. The main benefit of the asyncronous LoggerConfig is that when its 
queue isn’t full it will return back to the application almost immediately. 
Other than that they pretty much function the same. So if you were to have an 
event somehow routed to both a synchronous and asynchronous LoggerConfig you 
would now be waiting for the synchronous event to complete logging AND for the 
asynchronous event to be placed in the queue. That makes no sense as you are 
making your application perform slightly worse than in the synchronous case by 
itself.

If you perceive some other benefit to using both an asynchronous and a 
synchronous LoggerConfig please share that.

If, by chance you simply want the SyslogAppender to behave asynchronously then 
wrap it in an AsyncAppender. 

Ralph

> On Apr 16, 2021, at 6:32 AM, Matt Sicker  wrote:
> 
> You should take a look at the routing appender for supporting what you want
> to do. You can certainly keep the same logger name. You’d simply route log
> events based on other metadata. See:
> http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender
> 
> On Fri, Apr 16, 2021 at 06:35 Lars-Fredrik Smedberg 
> wrote:
> 
>> Hi
>> 
>> We have different appenders, one file appender and one syslog appender
>> amongst others. We want the file appender to use a normal Logger and the
>> syslog appender using an AsyncLogger. When the different
>> applications/functions perform the logging they don't know if it will end
>> up in the file appender only or in both the file appender and syslog
>> appender. The syslog appender have a filter (AlertFilter) that decides if
>> the log event will be accepted or not. The file appender has no filter.
>> 
>> The configuration looks like below (important parts included, some
>> attributes masked):
>> 
>> Any suggestion on how to be able to use the same logger name (which
>> obviously is not allowed) or achieve something that works the same way?
>> 
>> Best regards, preciate any help
>> LF
>> 
>> 
>>  
>>
>>  
>>
>>> format="RFC5424" facility="LOCAL6"
>>includeMDC="false" enterpriseNumber="xyz" appName="xyz"
>> newLine="true" messageId="Alert" id="App">
>>  
>>
>>>filePattern="logs/application.log.%i.gz" immediateFlush="true"  >
>>  
>>  
>>
>>
>>  
>>  
>>
>>  
>>  
>>
>>  
>>
>>
>>  
>>
>>
>>  
>>
>>  
>> 
>> 
>> --
>> Med vänlig hälsning / Best regards
>> 
>> Lars-Fredrik Smedberg
>> 
>> STATEMENT OF CONFIDENTIALITY:
>> The information contained in this electronic message and any
>> attachments to this message are intended for the exclusive use of the
>> address(es) and may contain confidential or privileged information. If
>> you are not the intended recipient, please notify Lars-Fredrik Smedberg
>> immediately at itsme...@gmail.com, and destroy all copies of this
>> message and any attachments.
>> 



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

Re: Question on accessing the threadcontext in pattern vs lookup

[Ralph Goers]

Your assumption is correct, but there is a way to avoid the problem. The issue 
is that, as one might expect, the ThreadContext is thread specific. So when the 
pattern is resolved it will be on the thread where the event is to be written, 
not the thread that called the logging method.

You can avoid this problem by not using the ThreadContext directly. Instead, 
get the context data out of the LogEvent. It will contain the ThreadContext 
data at the time the LogEvent was created. However, that would give you exactly 
the same thing %X does, so what is the point?

Ralph

> On Apr 9, 2021, at 9:00 AM, Lars-Fredrik Smedberg  wrote:
> 
> Hi!
> 
> We are using different appenders with a pattern layout that both read
> values from ThreadContext using %X and through a custom lookup that
> internally access the ThreadContext
> 
> If we use a pattern such as "%X{testkey} $${m:testkey} %m" (the lookup
> assigned to prefix m access the same key from the ThreadContext) and then
> use our appender in an AsyncLogger then we get the correct value for the
> %X{testkey} but not for $${m:testkey}.
> 
> I assume the message is formatted on the caller thread but that the lookup
> part of the pattern is resolved on the async thread since it does not seem
> to find the key in the ThreadContext inside our lookup class?
> 
> Is the above the root cause to our problem? Is there a way around this? We
> really would like to use our custom lookup that use ThreadContext with
> async loggers.
> 
> Any help would be greatly apreciated
> Best regards
> LF
> 
> -- 
> Med vänlig hälsning / Best regards
> 
> Lars-Fredrik Smedberg
> 
> STATEMENT OF CONFIDENTIALITY:
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> address(es) and may contain confidential or privileged information. If
> you are not the intended recipient, please notify Lars-Fredrik Smedberg
> immediately at itsme...@gmail.com, and destroy all copies of this
> message and any attachments.



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

Re: log pattern - servlet context name with fallback on pid

[Ralph Goers]

It would be trivial to create a lookup that returns the pid but I am not sure I 
would want to create a lookup for just that OS value. If we did create a lookup 
it might be something like:

${web:servletContextName:-${os:pid}}

If you want that please create a Jira issue with perhaps suggestions as to what 
keys it should support.

Ralph

> On Mar 26, 2021, at 3:20 PM, Clément Guillaume  wrote:
> 
> Interesting, that didn't work (because it was printing the exact string
> "{${web:servletContextName}" when the servlet name was missing) but using
> your approach I got something that works:
> 
> %equals{${web:servletContextName}}{${web:servletContextName}}{%pid}
> 
> I wonder if a simpler solution exists though.
> 
> Thank you for your response.
> 
> On Fri, Mar 26, 2021 at 5:27 AM Volkan Yazıcı 
> wrote:
> 
>> Hello Clement,
>> 
>> I am not an expert on *PatternLayout* and lookups, but I think I have a
>> hypothesis about what is going wrong and how you can fix it.
>> 
>> *${web:servletContextName:-${sys:user.name }}* lookup
>> works, because the substitute is again a *lookup*. Though
>> *${web:servletContextName:-%pid}* lookup doesn't work, because the
>> substitute is a *pattern*. I think the following would do the trick:
>> *%equals{${web:servletContextName}}{}{%pid}*. Would you mind checking,
>> please?
>> 
>> Kind regards.
>> 
>> On Thu, Mar 25, 2021 at 2:32 AM Clément Guillaume 
>> wrote:
>> 
>>> Hello,
>>> 
>>> I'm trying to make a log pattern showing the servlet context name or, if
>>> missing, showing the process id.
>>> 
>>> ${web:servletContextName} %msg
>>> works well for servlet context name alone.
>>> 
>>> %pid %msg
>>> works well for process id alone.
>>> 
>>> ${web:servletContextName:-${sys:user.name}} %msg
>>> works well for servlet context name with fallback to username system
>>> property ,
>>> 
>>> ${web:servletContextName:-%pid} %msg
>>> does work for servlet context name with fallback to process id.
>>> 
>>> Am I missing something in my pattern?
>>> 
>>> Thank you
>>> 
>> 



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

Re: Syslog for Log4J 2 & 1

[Ralph Goers]

OK, now I understand.

The SyslogAppender is really just a SocketAppender with either the SyslogLayout 
or RFC5424Layout hardwired.  We’ve discussed allowing patterns in the message 
but never did it because some of the patterns available in the PatternLayout 
shouldn’t be available. But lately I have been adding the ability to specify 
patterns for other layouts and it should be done for this as well. For example, 
I just modified the GelfLayout to do that.  If you wouldn’t mid creating a Jira 
issue I will see if I can get it in the next release.

Ralph

> On Mar 25, 2021, at 11:38 AM, Subhajit Das  wrote:
> 
> Hi Ralph,
> 
> This is the logback manual: http://logback.qos.ch/manual/appenders.html. Here 
> syslog uses suffix patten. Which is then read by syslog server and starting 
> text (say “app: ”), to segregate application logs.
> This is the Log4J manual: 
> https://logging.apache.org/log4j/2.x/manual/appenders.html#SyslogAppender. 
> This does not discuss any suffix. There is an option to replace whole pattern.
> 
> I want to adapt first thing into second.
> 
> Thanks.
> 
> From: Ralph Goers<mailto:ralph.go...@dslextreme.com>
> Sent: 25 March 2021 10:27 PM
> To: Log4J Users List<mailto:log4j-user@logging.apache.org>
> Subject: Re: Syslog for Log4J 2 & 1
> 
> I don’t understand what you mean by a “suffix pattern”. Can you please 
> elaborate?
> 
> Ralph
> 
>> On Mar 25, 2021, at 8:37 AM, Subhajit Das  wrote:
>> 
>> 
>> Hi,
>> 
>> We are using syslog in our organization with logback.
>> 
>> I want to use log4j instead. But, it seems that there is no suffix pattern 
>> or anything available.
>> 
>> How can I configure the same?
>> 
>> Thanks.
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 



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

Re: Syslog for Log4J 2 & 1

[Ralph Goers]

I don’t understand what you mean by a “suffix pattern”. Can you please 
elaborate?

Ralph

> On Mar 25, 2021, at 8:37 AM, Subhajit Das  wrote:
> 
> 
> Hi,
> 
> We are using syslog in our organization with logback.
> 
> I want to use log4j instead. But, it seems that there is no suffix pattern or 
> anything available.
> 
> How can I configure the same?
> 
> Thanks.



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

Re: Deadlock observed

[Ralph Goers]

One other thing. My expectation is that once the buffer is full you should 
continue to log but at the rate your underlying system can handle. This 
wouldn’t be a deadlock but if the rate at which you are logging is higher than 
the system can write the result will be that the application slows down.

If you are truly seeing a deadlock then it is possible there is a problem in 
the disruptor but I have very little experience with that and would need Remko 
to weigh in.

Ralph

> On Mar 14, 2021, at 12:26 AM, Ralph Goers  wrote:
> 
> Yes, it rings bells and really should have a slot on our FAQ page (although 
> the question really isn’t asked all that frequently).
> 
> First it means that you are logging faster than your system can handle. The 
> proper response is to figure out why you are logging so much and try to 
> reduce it or use an alternative destination that is faster. For example, if 
> you are logging to a file you may need to improve the hardware or increase 
> the buffer size. 
> 
> As you observed your buffer has filled up. The default behavior is for 
> threads to wait until there is an empty slot. 
> 
> Remko is the real expert on this but I will take a stab at answering your 
> question. The threads below show that they are in handleRingBufferFull. That 
> method has 3 options to choose from based on how you have configured the 
> asyncQueueFullPolicy. You basically have 3 choices:
> Wait for an open slot (the default)
> Resort to logging synchronously.
> Discard log events.
> 
> You should look at 
> https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/async/AsyncQueueFullPolicy.html
>  
> <https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/async/AsyncQueueFullPolicy.html>.
>  Note that option 2 above (synchronous) is only used by Log4j in certain 
> circumstances and there isn’t an option to specify that, so the only real 
> options are the default behavior, discarding, or create a custom 
> AsyncQueueFullPolicy.
> 
> Ralph
> 
> 
> 
>> On Mar 13, 2021, at 10:32 PM, Leon Finker  wrote:
>> 
>> HI,
>> 
>> Using log4j2 1.13.1 with disruptor 3.4.2. Linux CentOS. JRE 11.0.5
>> Using the following JRE args:
>> -DAsyncLogger.RingBufferSize=32768
>> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
>> -Dlog4j.configurationFile=...
>> 
>> The disruptor queue has filled up. And we've observed deadlock with
>> the interesting threads stuck like the following. Disruptor processing
>> thread seems to be waiting to process events and all the other threads
>> locked up on trying to publish the events.
>> 
>> "Log4j2-TF-1-AsyncLogger[AsyncContext@5cb0d902]-1" #23 daemon prio=5
>> os_prio=0 cpu=40099128.73ms elapsed=44102.95s tid=0x7f4c2ca34000
>> nid=0x611a runnable  [0x7f4bfdcfc000]
>>  java.lang.Thread.State: RUNNABLE
>>   at
>> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
>>   at
>> com.lmax.disruptor.BatchEventProcessor.processEvents(BatchEventProcessor.java:159)
>>   at
>> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:125)
>>   at java.lang.Thread.run(java.base@11.0.5/Thread.java:834)
>> 
>>  Locked ownable synchronizers:
>>   - None
>> 
>> 
>> "xxx" #268 prio=5 os_prio=0 cpu=7051742.32ms elapsed=43967.04s
>> tid=0x7f4c2e6ea800 nid=0x649d runnable  [0x7f49f77dd000]
>>  java.lang.Thread.State: TIMED_WAITING (parking)
>>   at jdk.internal.misc.Unsafe.park(java.base@11.0.5/Native Method)
>>   at java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.5
>> /LockSupport.java:357)
>>   at
>> com.lmax.disruptor.MultiProducerSequencer.next(MultiProducerSequencer.java:136)
>>   at
>> com.lmax.disruptor.MultiProducerSequencer.next(MultiProducerSequencer.java:105)
>>   at com.lmax.disruptor.RingBuffer.publishEvent(RingBuffer.java:465)
>>   at com.lmax.disruptor.dsl.Disruptor.publishEvent(Disruptor.java:331)
>>   at
>> org.apache.logging.log4j.core.async.AsyncLoggerDisruptor.enqueueLogMessageWhenQueueFull(AsyncLoggerDisruptor.java:230)
>>   - locked <0x000701017288> (a java.lang.Object)
>>   at
>> org.apache.logging.log4j.core.async.AsyncLogger.handleRingBufferFull(AsyncLogger.java:246)
>>   at
>> org.apache.logging.log4j.core.async.AsyncLogger.publish(AsyncLogger.java:230)
>>   at
>> org.apache.logging.log4j.core.async.AsyncLogger.logWithThreadLocalTranslator(AsyncLogger.java:225)
>>   at
>> o