[ANNOUNCE] Apache Log4j Tools `0.9.0` released
Apache Log4j Tools team is pleased to announce the `0.9.0` release. This project provides tooling internally used by the Apache Log4j project. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/tools == Release Notes This minor release contains small bug fixes and improvements. === Added * Add `skip` parameter to all Maven goals (#121) * Support multiple index and type templates in the `log4j-docgen:generate-documentation` configuration (#122) * Add support for the `@PluginValue` annotation. (#123) === Changed * Website is migrated to Antora (apache/logging-log4j2#2443) === Fixed * Fix handling of subclassed plugins in Log4j Docgen (#120) === Updated * Update `commons-io:commons-io` to version `2.16.1` (#114) * Update `org.apache.logging:logging-parent` to version `11.0.0` (#115) * Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to version `3.13.0` (#118) * Update `org.codehaus.modello:modello-maven-plugin` to version `2.4.0` (#119) * Update `org.xmlunit:xmlunit-assertj3` to version `2.10.0` (#116) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piotr, Thanks for the reminder. I did in fact do this, it had already been included in Thad’s solution. The idea of my email was to describe changes I made to Thad’s code. I now realize that it would have been smarter (and more useful to future mailing list readers) if I had included the rest as well. So here’s my full web.xml. Together with the LogListener.java I posted earlier, this achieves what I was trying to do. - http://www.w3.org/2001/XMLSchema-instance; xmlns="http://xmlns.jcp.org/xml/ns/javaee; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; id="WebApp_ID" version="3.1"> com.mycorp.server.rest.listeners.LogListener log4jServletFilter org.apache.logging.log4j.web.Log4jServletFilter log4jServletFilter /* REQUEST FORWARD INCLUDE ERROR ASYNC isLog4jAutoInitializationDisabled true - Thanks as well for your two other suggestions. This is very much appreciated. With kind regards Piers -- Piers Uso Walter ilink Kommunikationssysteme GmbH Kurfuerstendamm 67, 10707 Berlin, Germany +49 (30) 28526-185 > Am 31.03.2024 um 22:54 schrieb Piotr P. Karwasz : > > Hi Piers, > > On Sun, 31 Mar 2024 at 22:37, Piers Uso Walter wrote: >> >> Thad, >> >> >> Thanks so much. This looks exactly what I want to do. >> But somehow I never got your code to work. >> >> ... >> >> I made these changes to your code: >> >> 1. >> LogListener is now a subclass of Log4jServletContextListener, instead of >> just implementing ServletContextListener. >> So I’m only declaring a single listener in web.xml. >> >> 2. >> I’m not using the servlet init parameter >> Log4jWebSupport.LOG4J_CONFIG_LOCATION to set the config file location. >> Instead, I’m initializing a log4j Configurator from the file. > > Consider also setting the servlet init parameter > `isLog4jAutoInitializationDisabled` to `true` to disable the servlet > container initializer. > > Piotr > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org >
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piers, On Sun, 31 Mar 2024 at 22:37, Piers Uso Walter wrote: > > Thad, > > > Thanks so much. This looks exactly what I want to do. > But somehow I never got your code to work. > > ... > > I made these changes to your code: > > 1. > LogListener is now a subclass of Log4jServletContextListener, instead of just > implementing ServletContextListener. > So I’m only declaring a single listener in web.xml. > > 2. > I’m not using the servlet init parameter > Log4jWebSupport.LOG4J_CONFIG_LOCATION to set the config file location. > Instead, I’m initializing a log4j Configurator from the file. Consider also setting the servlet init parameter `isLog4jAutoInitializationDisabled` to `true` to disable the servlet container initializer. Piotr ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piers,
On Wed, 20 Mar 2024 at 17:09, Piers Uso Walter wrote:
> Am I trying something unusual here when I attempt to make the app decide
> where the log4j configuration file is located?
> Is there any other way in which I can achieve this?
> Is there an API for this?
Sorry for the late answer.
There are two solutions I could think of:
1. You could use a custom system variable (e.g.
`ilink.log4j2.configurationFile` and place:
log4jConfiguration
${sys:ilink.log4j2.configurationFile:-classpath:path_to_default_config_file
2. You could write container specific documentation:
* Tomcat supports the possibility to override context parameters
in an appropriate `context.xml` file:
https://tomcat.apache.org/tomcat-9.0-doc/config/index.html
* I don't have too much experiance with JBoss, but it supports
variable substitution in web descriptors and you could use a
`jboss-web.xml` file to prevent Tomcat from using it.
Piotr
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Jeff, Thanks for your suggestion. I ended up doing it slightly different (see my response to Thad Humphries). However, I’ll keep your idea in mind because the ability to both include a standard configuration in the app and also optionally modifying this configuration via an external config file seems interesting. I can easily see that we might want to do this in the future. With kind regards Piers -- Piers Uso Walter ilink Kommunikationssysteme GmbH Kurfuerstendamm 67, 10707 Berlin, Germany +49 (30) 28526-185 > Am 21.03.2024 um 07:19 schrieb jeffrey.tho...@t-systems.com: > > Hi Piers, > > I am not from Log4j Team - just a user like you :) > > We have a similar situation with internal distribution configuration and > external "customer" configuration. > > What we are now doing is programmatically creating a CompositeConfiguration > with the internal config and external config and reconfiguring Log4j early in > our startup. > > Cheers, Jeff
Re: log4j initialization does not seem to happen when Tomcat service is started
Thad,
Thanks so much. This looks exactly what I want to do.
But somehow I never got your code to work.
I finally modified your approach a bit, and now it works for me.
I am now able to dynamically set the location of the log4j configuration file
in my app.
And this works not just when the app is deployed/redeployed, but also when the
Tomcat service is restarted after the app has been deployed.
I made these changes to your code:
1.
LogListener is now a subclass of Log4jServletContextListener, instead of just
implementing ServletContextListener.
So I’m only declaring a single listener in web.xml.
2.
I’m not using the servlet init parameter Log4jWebSupport.LOG4J_CONFIG_LOCATION
to set the config file location.
Instead, I’m initializing a log4j Configurator from the file.
-
LogListener.java:
public class LogListener extends Log4jServletContextListener {
@Override
public void contextDestroyed(ServletContextEvent event) {
super.contextDestroyed(event);
}
@Override
public void contextInitialized(ServletContextEvent event)
{
logConfigPath = … // Determine the path of the log
configuration file
Configurator.initialize(null, logConfigPath);
super.contextInitialized(event);
}
}
web.xml:
com.mycorp.server.rest.listeners.LogListener
-
Your email was instrumental for me being able to find this solution.
Thanks again :-)
With kind regards
Piers
--
Piers Uso Walter
ilink Kommunikationssysteme GmbH
Kurfuerstendamm 67, 10707 Berlin, Germany
+49 (30) 28526-185
> Am 21.03.2024 um 13:43 schrieb Thad Humphries :
>
> Piers,
>
> I've configured two webapps with the log4j2 configuration outside of the
> *war files. The approach I'll describe is working in Tomcat 8.5 and Tomcat
> 9.
>
> First I create a LogListener class for the webapp:
>
> public class LogListener implements ServletContextListener {
>
> private static final Logger LOGGER = LogManager.getLogger();
> private Log4jServletContextListener listener = new
> Log4jServletContextListener();
>
> @Override
> public void contextDestroyed(ServletContextEvent event) {
>listener.contextDestroyed(event);
> }
>
>
> @Override
> public void contextInitialized(ServletContextEvent event) {
>String loggerPath = "WEB-INF/classes/log4j2.xml";
>
>ServletContext context = event.getServletContext();
>String fileString = context.getInitParameter("log4jConfiguration");
>if (fileString != null && fileString.length() > 0
>&& !fileString.equals("*")) {
> if ((new File(fileString)).exists()) {
>loggerPath = fileString;
> }
>}
>event.getServletContext().setInitParameter(
> Log4jWebSupport.LOG4J_CONFIG_LOCATION, loggerPath);
>listener.contextInitialized(event);
>LOGGER.info("logging properties from " + loggerPath);
> }
> }
>
>
> I declare the LogListener in web.xml and add some filtering:
>
>
>
>
> org.apache.logging.log4j.web.Log4jServletContextListener
>
>
>
>
> com.mycorp.server.rest.listeners.LogListener
>
>
>
>
>log4jServletFilter
>
> org.apache.logging.log4j.web.Log4jServletFilter
>
>
>log4jServletFilter
>/*
>REQUEST
>FORWARD
>INCLUDE
>ERROR
>ASYNC
>
>
>
>isLog4jAutoInitializationDisabled
>true
>
>
> Finally, in the Tomcat context file, META-INF/context.xml, I add the
> log4jConfiguration that LogListener wants:
>
> name="log4jConfiguration" override="false"
> value="/Users/admin/local/etc/my_logger.xml"/>
>
>
> When I start Tomcat, the first entry in the log is
>
> 12:23:23.439 INFO LogListener.contextInitialized() - logging properties
> from /Users/admin/local/etc/my_logger.xml
>
> At one time I had this working in Jetty, but I no longer remember where to
> set its context.
>
> We've installed these apps on numerous servers, both Linux (of various
> distros) and macOS. AFAIK, they're also running on a number of Windows
> servers as well. Logging works everywhere.
>
> On Wed, Mar 20, 2024 at 12:09 PM Piers Uso Walter
> wrote:
>
>> Hi Piotr,
>>
>> Thanks for your email.
>>
>> Here is what I’m trying to do:
>> The previous version of our app stores the log4j configuration within the
>> war file.
>> This works fine but is annoying if one wants to change any logging setting
>> (unpacking the war, changing the configu
Re: log4j initialization does not seem to happen when Tomcat service is started
Piers,
I've configured two webapps with the log4j2 configuration outside of the
*war files. The approach I'll describe is working in Tomcat 8.5 and Tomcat
9.
First I create a LogListener class for the webapp:
public class LogListener implements ServletContextListener {
private static final Logger LOGGER = LogManager.getLogger();
private Log4jServletContextListener listener = new
Log4jServletContextListener();
@Override
public void contextDestroyed(ServletContextEvent event) {
listener.contextDestroyed(event);
}
@Override
public void contextInitialized(ServletContextEvent event) {
String loggerPath = "WEB-INF/classes/log4j2.xml";
ServletContext context = event.getServletContext();
String fileString = context.getInitParameter("log4jConfiguration");
if (fileString != null && fileString.length() > 0
&& !fileString.equals("*")) {
if ((new File(fileString)).exists()) {
loggerPath = fileString;
}
}
event.getServletContext().setInitParameter(
Log4jWebSupport.LOG4J_CONFIG_LOCATION, loggerPath);
listener.contextInitialized(event);
LOGGER.info("logging properties from " + loggerPath);
}
}
I declare the LogListener in web.xml and add some filtering:
org.apache.logging.log4j.web.Log4jServletContextListener
com.mycorp.server.rest.listeners.LogListener
log4jServletFilter
org.apache.logging.log4j.web.Log4jServletFilter
log4jServletFilter
/*
REQUEST
FORWARD
INCLUDE
ERROR
ASYNC
isLog4jAutoInitializationDisabled
true
Finally, in the Tomcat context file, META-INF/context.xml, I add the
log4jConfiguration that LogListener wants:
When I start Tomcat, the first entry in the log is
12:23:23.439 INFO LogListener.contextInitialized() - logging properties
from /Users/admin/local/etc/my_logger.xml
At one time I had this working in Jetty, but I no longer remember where to
set its context.
We've installed these apps on numerous servers, both Linux (of various
distros) and macOS. AFAIK, they're also running on a number of Windows
servers as well. Logging works everywhere.
On Wed, Mar 20, 2024 at 12:09 PM Piers Uso Walter
wrote:
> Hi Piotr,
>
> Thanks for your email.
>
> Here is what I’m trying to do:
> The previous version of our app stores the log4j configuration within the
> war file.
> This works fine but is annoying if one wants to change any logging setting
> (unpacking the war, changing the configuration, repacking the war,
> redeploying).
>
> For the next version of our app, I would like to move the log4j
> configuration to a place outside of the war.
> For Tomcat I would like to use $catalina.home/conf/ilink/GW-log4j2.xml
> and for Wildlfy I would like to use
> $jboss.home.dir/conf/ilink/GW-log4j2.xml
> (with $catalina.home and $jboss.home.dir being system properties that are
> defined in the two servers)
>
> Since the configuration file path is only known at runtime I cannot use
> the servlet initialization parameter ‘log4jConfiguration’ in web.xml.
> So I looked at log4j's automatic configuration [1].
> This led me to the idea to use a ServletContextListener to determine if
> the app is running in WIldFly or in Tomcat and then setting the system
> property $log4j.configurationFile accordingly.
>
> But as you point out, the ServletContextListener is executed too late.
> That explains why it does not work in my case 2 (when the Tomcat service
> is restarted).
> I still don’t understand why it does work in my case 1 (when the app is
> being redeployed in a running Tomcat), but that is not so important as this
> does not seem to be the correct approach anyway.
>
> Also, thanks for pointing out what should have been obvious: that other
> web apps on the same server will be affected when I set the
> `log4j2.configurationFile` property.
> Not a good idea.
>
> Am I trying something unusual here when I attempt to make the app decide
> where the log4j configuration file is located?
> Is there any other way in which I can achieve this?
> Is there an API for this?
>
> Thanks,
> Piers
>
> [1]
> https://logging.apache.org/log4j/2.x/manual/configuration.html#automatic-configuration
>
>
>
> > Am 15.03.2024 um 07:45 schrieb Piotr P. Karwasz >:
> >
> > Hi Piers,
> >
> > On Thu, 14 Mar 2024 at 14:08, Piers Uso Walter
> wrote:
> >> However, what I was trying to achieve by using a servlet context
> listener was to be able to set the location of the log4j configuration file
> at run time.
> >> I’m trying to make the app compatible with different app servers where
> configuration files are typically placed in different locations.
> >> So I’m figuring out at run time which
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piers, I am not from Log4j Team - just a user like you :) We have a similar situation with internal distribution configuration and external "customer" configuration. What we are now doing is programmatically creating a CompositeConfiguration with the internal config and external config and reconfiguring Log4j early in our startup. Cheers, Jeff sent with Corporate Mobile Service On Mar 20, 2024 5:10 PM, Piers Uso Walter wrote: Hi Piotr, Thanks for your email. Here is what I’m trying to do: The previous version of our app stores the log4j configuration within the war file. This works fine but is annoying if one wants to change any logging setting (unpacking the war, changing the configuration, repacking the war, redeploying). For the next version of our app, I would like to move the log4j configuration to a place outside of the war. For Tomcat I would like to use $catalina.home/conf/ilink/GW-log4j2.xml and for Wildlfy I would like to use $jboss.home.dir/conf/ilink/GW-log4j2.xml (with $catalina.home and $jboss.home.dir being system properties that are defined in the two servers) Since the configuration file path is only known at runtime I cannot use the servlet initialization parameter ‘log4jConfiguration’ in web.xml. So I looked at log4j's automatic configuration [1]. This led me to the idea to use a ServletContextListener to determine if the app is running in WIldFly or in Tomcat and then setting the system property $log4j.configurationFile accordingly. But as you point out, the ServletContextListener is executed too late. That explains why it does not work in my case 2 (when the Tomcat service is restarted). I still don’t understand why it does work in my case 1 (when the app is being redeployed in a running Tomcat), but that is not so important as this does not seem to be the correct approach anyway. Also, thanks for pointing out what should have been obvious: that other web apps on the same server will be affected when I set the `log4j2.configurationFile` property. Not a good idea. Am I trying something unusual here when I attempt to make the app decide where the log4j configuration file is located? Is there any other way in which I can achieve this? Is there an API for this? Thanks, Piers [1] https://logging.apache.org/log4j/2.x/manual/configuration.html#automatic-configuration > Am 15.03.2024 um 07:45 schrieb Piotr P. Karwasz : > > Hi Piers, > > On Thu, 14 Mar 2024 at 14:08, Piers Uso Walter wrote: >> However, what I was trying to achieve by using a servlet context listener >> was to be able to set the location of the log4j configuration file at run >> time. >> I’m trying to make the app compatible with different app servers where >> configuration files are typically placed in different locations. >> So I’m figuring out at run time which app server the app is running in, and >> based on that I know where to expect the log4j configuration file. > > Can provide more details as to where the path to the configuration > file is actually stored? If you change the `log4j2.configurationFile` > property, other web apps on the same server will be affected, which > might be an unpleasant surprise to users. There are less invasive ways > to do that. > > I also wonder if maintaining container specific code is worth the > effort. Many application servers have a detailed guide to configuring > logging (e.g. WildFly[1]). Users might be unwilling to learn yet > another way to configure logging. > > Sure, Tomcat is an exception, that is why I maintain a small set of > Log4j Core plugins and Tomcat extensions[2] to help users > administering logging at a global level. > > Piotr > > [1] https://docs.wildfly.org/31/Admin_Guide.html#Logging > [2] https://github.com/copernik-eu/log4j-tomcat > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org >
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piotr, Thanks for your email. Here is what I’m trying to do: The previous version of our app stores the log4j configuration within the war file. This works fine but is annoying if one wants to change any logging setting (unpacking the war, changing the configuration, repacking the war, redeploying). For the next version of our app, I would like to move the log4j configuration to a place outside of the war. For Tomcat I would like to use $catalina.home/conf/ilink/GW-log4j2.xml and for Wildlfy I would like to use $jboss.home.dir/conf/ilink/GW-log4j2.xml (with $catalina.home and $jboss.home.dir being system properties that are defined in the two servers) Since the configuration file path is only known at runtime I cannot use the servlet initialization parameter ‘log4jConfiguration’ in web.xml. So I looked at log4j's automatic configuration [1]. This led me to the idea to use a ServletContextListener to determine if the app is running in WIldFly or in Tomcat and then setting the system property $log4j.configurationFile accordingly. But as you point out, the ServletContextListener is executed too late. That explains why it does not work in my case 2 (when the Tomcat service is restarted). I still don’t understand why it does work in my case 1 (when the app is being redeployed in a running Tomcat), but that is not so important as this does not seem to be the correct approach anyway. Also, thanks for pointing out what should have been obvious: that other web apps on the same server will be affected when I set the `log4j2.configurationFile` property. Not a good idea. Am I trying something unusual here when I attempt to make the app decide where the log4j configuration file is located? Is there any other way in which I can achieve this? Is there an API for this? Thanks, Piers [1] https://logging.apache.org/log4j/2.x/manual/configuration.html#automatic-configuration > Am 15.03.2024 um 07:45 schrieb Piotr P. Karwasz : > > Hi Piers, > > On Thu, 14 Mar 2024 at 14:08, Piers Uso Walter wrote: >> However, what I was trying to achieve by using a servlet context listener >> was to be able to set the location of the log4j configuration file at run >> time. >> I’m trying to make the app compatible with different app servers where >> configuration files are typically placed in different locations. >> So I’m figuring out at run time which app server the app is running in, and >> based on that I know where to expect the log4j configuration file. > > Can provide more details as to where the path to the configuration > file is actually stored? If you change the `log4j2.configurationFile` > property, other web apps on the same server will be affected, which > might be an unpleasant surprise to users. There are less invasive ways > to do that. > > I also wonder if maintaining container specific code is worth the > effort. Many application servers have a detailed guide to configuring > logging (e.g. WildFly[1]). Users might be unwilling to learn yet > another way to configure logging. > > Sure, Tomcat is an exception, that is why I maintain a small set of > Log4j Core plugins and Tomcat extensions[2] to help users > administering logging at a global level. > > Piotr > > [1] https://docs.wildfly.org/31/Admin_Guide.html#Logging > [2] https://github.com/copernik-eu/log4j-tomcat > > ----- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org >
RE: Deprecation of Log4j Supplier in 2.x...why?
Hallo Piotr, Oh geez another set of Nullability annotations lol... To explicitly answer your question I *personally* would probably prefer #2... it is relatively small and those who don't want the JAR could explicitly exclude it. Regarding compiler warnings... We have an old monolith large build - between Maven and Java there are already so many spammy messages in our build logs - new Java open/closed package warnings from the JDK module system, Javadoc, Checkstyle, and, and, and ... and then add in hundreds if not thousands of deprecation warnings from Log4j and the build logs really blow up. If I have a chance to take a chunk out of that by asking a dumb question, I will If building locally, excessive log messages (i.e. IntelliJ for me) feels like it really slows the build down. But way more annoying is the effect of the deprecations in the IDE. Suddenly every logging statement is highlighting yellow and it is hard to find the "real" problems when validating the source-file. I really don't want to downgrade us to an older version of Log4j 2.x to avoid this and miss out on future maintenance/fixes. I personally don't like using @Deprecated to convey "intent-to-remove" without a documented and *available* replacement for the deprecated code. @SuppressWarnings at this scale is not an option - since it will also suppress valid warnings .. and ultimately need to be verified and removed later ... forces a maintenance task on us later. And now for my uninformed opinion about the nullabilty-annotations... About nullability annotations. I am not up-to-date on the discussion - never even heard of JSpecify until you mentioned it. However, we also very recently just made a huge push to get from the 'javax' to the 'jakarta' package namespace and where possible I have really been pushing my colleagues to start using the Jakarta annotations/constraints. Plus, we are integrating Spring into our monolith for which we are also using Jakarta constraint annotation validation. So after a *lot* of effort, we finally have everything sort of aligned with Jakarta EE right now. In addition, we have also partially implemented byte-buddy plugins on some of our internal JARs to insert runtime validation of @NotNull / @Nonnull Jakarta constraints. The idea of yet another set of nullability annotations doesn't excite me. ☹ I checked out the JSpecify documentation and at first glance I am not sure what the big benefits are - and the idea of a @NullMarked and all the conditional meanings is one I cannot really imagine my team of old-school developers will use or even understand. Plus you still end up bringing in Jakarta for all the other constraint validations (@NotBlank, @Positive, etc.) and non-constraint annotations (@Nullable, @PostConstruct, @PreDestroy, etc.) and so much of the tooling already works with this (IDE, Spring, etc.). I watched a video about JSpecify from Kevin Bourrillion (about 3 months old) - it doesn't really seem finalized yet and he said "It is a reference implementation. Prepare for a bumpy ride. You definitely should *not* include it your toolchain for your actual build" (paraphrasing). Plus he said that most tooling will not yet recognize the annotations. (https://www.youtube.com/watch?v=HS_kA42YNkU / 17:00 minutes in). He did argue at the beginning of the video that the 'javax.annotation' package is dormant for 11 years - while that might be true, it looks like the Jakarta annotation-api specification / JSR-175 is alive and well. (https://jakarta.ee/specifications/annotations/2.0/annotations-spec-2.0.html#specification-scope). Since we work with a lot of third-party libraries and some of them are older - I am not sure how to feel about the decisions to exclude the annotations on method parameters and possibly not on method scope. A lot of those 3rd-Party APIs (i.e Apache Axis2) don't specify nullability or even document the null-behavior. We have been using the Nullability annotations to wrap calls to these APIs on field parameters to specifically "document" what the behavior is. I personally like the explicitness of seeing the @Nullable/@NotNull annotations on each field - even if it might feel "bulky". I often find myself drilling through 20-layers of third-party API just to figure out what the heck it is going to do with a null argument (yes even log4j ). Cheers, Jeff -Original Message- From: Piotr P. Karwasz Sent: Friday, March 15, 2024 9:41 AM To: Log4J Users List Subject: Re: Deprecation of Log4j Supplier in 2.x...why? Hi Jeff, On Fri, 15 Mar 2024 at 02:43, wrote: > Our builds are now ***full*** of deprecation warnings. The IDE shows > deprecation highlighting everywhere. Also, CI builds i.e. with Sonar evaluate > use of deprecated API as Code Smells and Quality Gates fail. When SQ quality > gates fail our downstream job
Re: Deprecation of Log4j Supplier in 2.x...why?
Hi Jeff, On Fri, 15 Mar 2024 at 02:43, wrote: > Our builds are now ***full*** of deprecation warnings. The IDE shows > deprecation highlighting everywhere. Also, CI builds i.e. with Sonar evaluate > use of deprecated API as Code Smells and Quality Gates fail. When SQ quality > gates fail our downstream jobs don't trigger. Since you are one of the few users that pays attention to compiler warnings, may I ask you for an opinion? We are considering annotating our code with JSpecify nullability annotations[1], which has a big chance to become THE nullability annotation standard (instead of the 15-th nullability annotation standard). Which one of these options would you prefer: * we add JSpecify as a `provided` dependency: Maven will not download the dependency in projects using Log4j API, but users will get many compiler warnings about missing annotations. These are just warnings: missing annotations cause no problems at runtime. Of course a user can get rid of the warnings by including JSpecify in its own dependencies, * we add JSpecify as a `compile` dependency and force users to download the (2 KiB) JAR file. Piotr [1] https://jspecify.dev/ - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Deprecation of Log4j Supplier in 2.x...why?
Hi Jeff, On Fri, 15 Mar 2024 at 07:50, wrote: > Yes the Javadoc did a fine job of explaining the reason for the change and I > understood it, but there are so many side-effects from deprecating those > APIs. My question was more of a "why do this in advance?" The deprecation was introduced as a requirement of semantic versioning: "Before you completely remove the functionality in a new major release there should be at least one minor release that contains the deprecation so that users can smoothly transition to the new API."[1] However in January this year (cf. [2]) we decided that we will not release a Log4j API 3.x version in the foreseeable future. We will only release a major version of our logging backend Log4j Core. I guess this means we can remove the @Deprecated annotation. Personally it bothers me too to introduce all those `@SuppressWarnings` annotations. > It took us unfortunately a long time to get to 2.x and I am pretty sure we > won't be jumping on the 3.0 version at release, so the idea of dealing with > those deprecations for another 1-2 years is sobering. While we chose the same Java baseline as Spring Boot 3.x (Java 17), Log4j Core 3.x will be easier to deploy, since it will just require the replacement of a runtime dependency. Piotr [1] https://semver.org/#how-should-i-handle-deprecating-functionality [2] https://lists.apache.org/thread/p2lgr3xtt9hq77j7r67r8x1tc1z7kbol - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Deprecation of Log4j Supplier in 2.x...why?
Hey Piotr, Thanks for the quick response. Yes the Javadoc did a fine job of explaining the reason for the change and I understood it, but there are so many side-effects from deprecating those APIs. My question was more of a "why do this in advance?" And, in this case, even when switching to the JRE Supplier, it is a no code change (on "my" side) I think since the two interfaces are quasi identical... and a drop-in replacement which makes the deprecation more frustrating. It took us unfortunately a long time to get to 2.x and I am pretty sure we won't be jumping on the 3.0 version at release, so the idea of dealing with those deprecations for another 1-2 years is sobering. Cheers, Jeff sent with Corporate Mobile Service On Mar 15, 2024 7:29 AM, "Piotr P. Karwasz" wrote: Hi Jeff, On Fri, 15 Mar 2024 at 02:43, wrote: > One of the great new features of Log4j2 is the lambda lazy logging. > > Since we migrated to Log4j2 we have liberally been trying to take advantage > of this where we can. > > In the last few releases though, in preparation for Log4j 3.x the Log4j > Supplier has been deprecated without replacement. Sorry, if we were not specific enough in the Javadoc[1]. We would like to replace `org.apache.logging.log4j.util.Supplier` with `java.util.function.Supplier`, which is a source compatible change: the compiler will just convert lambdas to another interface. However this is more of a very long-term plan, which would probably require an entirely new package name and `Logger` interface. Effectively we should remove the `@Deprecated` annotation from our code and just keep the Javadoc description. Piotr [1] https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/Supplier.html ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piers, On Thu, 14 Mar 2024 at 14:08, Piers Uso Walter wrote: > However, what I was trying to achieve by using a servlet context listener was > to be able to set the location of the log4j configuration file at run time. > I’m trying to make the app compatible with different app servers where > configuration files are typically placed in different locations. > So I’m figuring out at run time which app server the app is running in, and > based on that I know where to expect the log4j configuration file. Can provide more details as to where the path to the configuration file is actually stored? If you change the `log4j2.configurationFile` property, other web apps on the same server will be affected, which might be an unpleasant surprise to users. There are less invasive ways to do that. I also wonder if maintaining container specific code is worth the effort. Many application servers have a detailed guide to configuring logging (e.g. WildFly[1]). Users might be unwilling to learn yet another way to configure logging. Sure, Tomcat is an exception, that is why I maintain a small set of Log4j Core plugins and Tomcat extensions[2] to help users administering logging at a global level. Piotr [1] https://docs.wildfly.org/31/Admin_Guide.html#Logging [2] https://github.com/copernik-eu/log4j-tomcat - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Deprecation of Log4j Supplier in 2.x...why?
Hi Jeff, On Fri, 15 Mar 2024 at 02:43, wrote: > One of the great new features of Log4j2 is the lambda lazy logging. > > Since we migrated to Log4j2 we have liberally been trying to take advantage > of this where we can. > > In the last few releases though, in preparation for Log4j 3.x the Log4j > Supplier has been deprecated without replacement. Sorry, if we were not specific enough in the Javadoc[1]. We would like to replace `org.apache.logging.log4j.util.Supplier` with `java.util.function.Supplier`, which is a source compatible change: the compiler will just convert lambdas to another interface. However this is more of a very long-term plan, which would probably require an entirely new package name and `Logger` interface. Effectively we should remove the `@Deprecated` annotation from our code and just keep the Javadoc description. Piotr [1] https://logging.apache.org/log4j/2.x/javadoc/log4j-api/org/apache/logging/log4j/util/Supplier.html - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Deprecation of Log4j Supplier in 2.x...why?
Hello Log4j Team, One of the great new features of Log4j2 is the lambda lazy logging. Since we migrated to Log4j2 we have liberally been trying to take advantage of this where we can. In the last few releases though, in preparation for Log4j 3.x the Log4j Supplier has been deprecated without replacement. I get why you did this, but ... "why?" did you do this? Our builds are now ***full*** of deprecation warnings. The IDE shows deprecation highlighting everywhere. Also, CI builds i.e. with Sonar evaluate use of deprecated API as Code Smells and Quality Gates fail. When SQ quality gates fail our downstream jobs don't trigger. I read Hibernate did something similar to indicate "intent" without replacement, but they ultimately ended up reverting that change. Cheers, Jeff
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piotr, Thanks for your explanation. Indeed, once I hard code the path to the log4j configuration file into web.xml, logging works in both cases (app undeployment/deployment as well as Tomcat shutdown/restart). However, what I was trying to achieve by using a servlet context listener was to be able to set the location of the log4j configuration file at run time. I’m trying to make the app compatible with different app servers where configuration files are typically placed in different locations. So I’m figuring out at run time which app server the app is running in, and based on that I know where to expect the log4j configuration file. Is there any way to do this? Or am I stuck with using a fixed path via web.xml? Thanks, Piers > Am 13.03.2024 um 23:35 schrieb Piotr P. Karwasz : > > Hi Piers, > > On Wed, 13 Mar 2024 at 22:29, Piers Uso Walter wrote: >> 2024-03-13T19:49:02.609143Z Catalina-utility-1 INFO >> Log4jServletContextListener triggered a Log4j context initialization. >> >> Case 2: >> However, if I stop and restart the Tomcat service (with the war file having >> been previously deployed), the app no longer logs anything and I don’t see a >> catalina log line about Log4j context initialization: > > The message in the first line is not logged through Log4j Core, but > the status logger (an internal logging system of the Log4 API). You > can set the level of the status logger using the > `log4j2.StatusLogger.level` property. By default it only shows `ERROR` > messages, but it changes level based on the `status` property > >> I configured a servlet context listener in order to be able to set the >> system property log4j.configurationFile upon application start. >> This allows me to place the log4j configuration file outside of the war file. > > A servlet context listener is not the right tool for this, since it is > executed **after** Log4j's `ServletContainerInitializer`. > You should rather specify the property as a servlet context init > parameter. See the current documentation: > > https://logging.apache.org/log4j/2.x/manual/webapp.html#configuration > > or a preview of the documentation of the next major version: > > https://logging.staged.apache.org/log4j/jakarta/latest/#log4j-jakarta-web-configuration > >> This is my web.xml: >> >> http://www.w3.org/2001/XMLSchema-instance; >> xmlns="http://xmlns.jcp.org/xml/ns/javaee; >> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee >> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; id="WebApp_ID" >> version="3.1"> >> >> >> >> >> de.ilink.cloud.ucc.gw.LdapGwServletContextListener >> >> >> > > You should add: > > >log4jConfiguration >path_to_your_config_file_or_resource > > > Also if your context listener uses logging, you might want to register > a `Log4jServletContextListener` manually, so it shuts down **after** > your listener: > > > > org.apache.logging.log4j.web.Log4jServletContextListener > > > > > de.ilink.cloud.ucc.gw.LdapGwServletContextListener > > > Piotr > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: log4j initialization does not seem to happen when Tomcat service is started
Hi Piers, On Wed, 13 Mar 2024 at 22:29, Piers Uso Walter wrote: > 2024-03-13T19:49:02.609143Z Catalina-utility-1 INFO > Log4jServletContextListener triggered a Log4j context initialization. > > Case 2: > However, if I stop and restart the Tomcat service (with the war file having > been previously deployed), the app no longer logs anything and I don’t see a > catalina log line about Log4j context initialization: The message in the first line is not logged through Log4j Core, but the status logger (an internal logging system of the Log4 API). You can set the level of the status logger using the `log4j2.StatusLogger.level` property. By default it only shows `ERROR` messages, but it changes level based on the `status` property > I configured a servlet context listener in order to be able to set the system > property log4j.configurationFile upon application start. > This allows me to place the log4j configuration file outside of the war file. A servlet context listener is not the right tool for this, since it is executed **after** Log4j's `ServletContainerInitializer`. You should rather specify the property as a servlet context init parameter. See the current documentation: https://logging.apache.org/log4j/2.x/manual/webapp.html#configuration or a preview of the documentation of the next major version: https://logging.staged.apache.org/log4j/jakarta/latest/#log4j-jakarta-web-configuration > This is my web.xml: > > http://www.w3.org/2001/XMLSchema-instance; > xmlns="http://xmlns.jcp.org/xml/ns/javaee; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; id="WebApp_ID" > version="3.1"> > > > > > de.ilink.cloud.ucc.gw.LdapGwServletContextListener > > > You should add: log4jConfiguration path_to_your_config_file_or_resource Also if your context listener uses logging, you might want to register a `Log4jServletContextListener` manually, so it shuts down **after** your listener: org.apache.logging.log4j.web.Log4jServletContextListener de.ilink.cloud.ucc.gw.LdapGwServletContextListener Piotr ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
log4j initialization does not seem to happen when Tomcat service is started
Hi all, I have a small web app that runs in Tomcat 9 and uses log4j 2 for logging. This works in one case and does not work in another case: Case 1: When I deploy the war file to Tomcat (copying the war file to the Tomcat webapps folder), everything works as expected. The log file is created (if missing) and the app’s log output appears in the log file. In the catalina log file I see that the Log4j context has been initialized (the two 'GW.war' lines are being written to stdout by my app): 13-Mar-2024 20:49:02.229 INFORMATION [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/Users/piers/Documents/Tomcat/apache-tomcat-9.0.86/webapps/GW.war] 13-Mar-2024 20:49:02.475 INFORMATION [Catalina-utility-1] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. GW.war: ServletContextListener started GW.war: System property log4j.configurationFile=/Users/piers/Documents/Tomcat/apache-tomcat-9.0.86/conf/ilink-LDAP-GW-log4j2.xml 2024-03-13T19:49:02.609143Z Catalina-utility-1 INFO Log4jServletContextListener triggered a Log4j context initialization. 13-Mar-2024 20:49:02.646 INFORMATION [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/Users/piers/Documents/Tomcat/apache-tomcat-9.0.86/webapps/GW.war] has finished in [417] ms Case 2: However, if I stop and restart the Tomcat service (with the war file having been previously deployed), the app no longer logs anything and I don’t see a catalina log line about Log4j context initialization: 13-Mar-2024 20:49:34.329 INFORMATION [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/Users/piers/Documents/Tomcat/apache-tomcat-9.0.86/webapps/GW.war] 13-Mar-2024 20:49:34.609 INFORMATION [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. GW.war: ServletContextListener started GW.war: System property log4j.configurationFile=/Users/piers/Documents/Tomcat/apache-tomcat-9.0.86/conf/ilink-LDAP-GW-log4j2.xml 13-Mar-2024 20:49:34.781 INFORMATION [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/Users/piers/Documents/Tomcat/apache-tomcat-9.0.86/webapps/GW.war] has finished in [452] ms I am not sure what I might be doing wrong here. I see that the deployment is being reported using different logger names (thread names?) in both cases: [Catalina-utility-1] vs. [main]. I don’t know if this should make a difference though. The app uses the servlet API 3.1. I included log4j-web-2.23.0.jar in WEB-INF/lib for proper initialization. (also included are log4j-api-2.23.0.jar, log4j-core-2.23.0.jar, and log4j-slf4j-impl-2.23.0.jar in case this might be relevant) I configured a servlet context listener in order to be able to set the system property log4j.configurationFile upon application start. This allows me to place the log4j configuration file outside of the war file. This is my web.xml: http://www.w3.org/2001/XMLSchema-instance; xmlns="http://xmlns.jcp.org/xml/ns/javaee; xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd; id="WebApp_ID" version="3.1"> de.ilink.cloud.ucc.gw.LdapGwServletContextListener I’m stuck at this point and would appreciate any ideas of what might be going on here. Piers -- Piers Uso Walter ilink Kommunikationssysteme GmbH ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
GraalVM support in Log4j Core
Hi all, For Q3-Q4 we plan to introduce native GraalVM support in Log4j Core. This can be implemented in at least two ways: * you can have slim binaries with only the Log4j Core components necessary for your configuration, * you can have larger binaries, but be able to digest any valid Log4j Core configuration file. Unfortunately we don't know which approach will be the best for most users. If you are using Log4j Core in a GraalVM application, please provide us some feedback in this Github discussion: https://github.com/apache/logging-log4j2/discussions/2364 Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 2.23.1 released
Apache Log4j team is pleased to announce the 2.23.1 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j == Release Notes This release contains several small fixes and some dependency updates. === Changed * Improve performance of `CloseableThreadContext#closeMap()` (#2296) === Fixed * Fix handling of `LoggerContextAware` lookups (#2309) * Fix NPE in `PatternProcessor` for a `UNIX_MILLIS` pattern (#2346) * Fix that parameterized message formatting doesn't throw an exception when there are insufficient number of parameters (#2343) * Fix `StatusLogger` log level filtering when debug mode is enabled (#2337) * Add `log4j2.StatusLogger.dateFormatZone` system property to set the time-zone `StatusLogger` uses to format `java.time.Instant`. Without this, formatting patterns accessing to time-zone-specific fields (e.g., year-of-era) cause failures. (#2322) * Fix `StatusLogger` to correctly read `log4j2.StatusLogger.properties` resource (#2354) * Fix stack overflow in `StatusLogger` (#2322) === Updated * Update `jakarta.activation:jakarta.activation-api` to version `2.1.3` (#2335) * Update `jakarta.mail:jakarta.mail-api` to version `2.1.3` (#2348) * Update `org.apache.commons:commons-compress` to version `1.26.0` (#2304) * Update `org.apache.commons:commons-dbcp2` to version `2.12.0` (#2344) * Update `org.apache.kafka:kafka-clients` to version `3.7.0` (#2326) * Update `org.eclipse.angus:angus-activation` to version `2.0.2` (#2336) * Update `org.eclipse.angus:jakarta.mail` to version `2.0.3` (#2349) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 2.23.0 released
The Apache Log4j team is pleased to announce the 2.23.0 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/2.x/ == Release Notes This release adds support for LMAX Disruptor 4.x and several performance and bug fixes. In order to maintain compatibility with JRE 8, support for LMAX Disruptor 3.x is maintained. === Added * Added support for LMAX Disruptor 4.x (#1821) === Changed * Simplify BND configuration after upgrade from version `6.4.1` to `7.0.0` === Deprecated * Deprecate the configuration attribute `verbose` (i.e., ` node to appear in any position in the configuration element. * Fix forgotten `threadName` field in `RingBufferLogEvent#clear()` (#2234) * Fix `StringBuilder` cache corruption on recursive access * Fixed use of `SecurityManager` in `LoaderUtil` where `AccessController::doPrivilege d` should only be invoked when a `SecurityManager` is installed. Some runtimes do not seem to have this method available. (#2129) * Fix `log4j-spring-cloud-config-client` dependencies to include only those required. (#2157) * Fix typo in Kubernetes `clientKeyData` configuration property. === Updated * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.1` (#2126) * Update `commons-codec:commons-codec` to version `1.16.1` (#2277) * Update `io.netty:netty-bom` to version `4.1.107.Final` (#2284) * Update `org.apache.logging:logging-parent` to version `10.6.0` (#2197) * Update `org.eclipse.jetty:jetty-bom` to version `9.4.54.v20240208` (#2287) * Update `org.jctools:jctools-core` to version `4.0.3` (#2270) * Update `org.springframework:spring-framework-bom` to version `5.3.32` (#2293) * Update `org.zeromq:jeromq` to version `0.6.0` (#2271) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 3.0.0-beta2 released
The Apache Log4j team is pleased to announce the 3.0.0-beta2 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/3.x/ == Release Notes This release provides a continuation of the modularisation process of Log4j Core. The following features were moved to separate artifacts: * The async logger feature was moved to `log4j-async-logger` and it was upgraded to use LMAX Disruptor 4.x. The async appender is still available by default in `log4j-core`. * The YAML configuration is available now in `log4j-config-yaml`. * The Java properties configuration was removed and replaced with a similar format based on `jackson-dataformat-properties` in a new `log4j-config-properties` artifact. Other features were removed: * Jetty 9.x users are encouraged to migrate to Jetty 10.x or later and replace `log4j-appserver` with `log4j-slf4j2-impl`. * Tomcat JULI support will be available from a third-party (cf. https://github.com/copernik-eu/log4j-plugins <https://github.com/copernik-eu/log4j-plugins>). * Apache Commons Logging users are encouraged to upgrade `commons-logging` to version 1.3.0 or later and remove `log4j-jcl`. * Support for the XML layout was dropped. * Support for JMX was dropped and will be replaced with a more recent technology. === Added * Add and update DSLs for setting up dependency injection for test and non-test code. (#2147) * Add a `ConfigurationExtension` mechanism to allow third-party JARs to extend the `` element. * Add a new properties configuration factory based on `jackson-dataformat-properties`. === Changed * Change the order of evaluation of `FormattedMessage` formatters. Messages are evaluated using `java.util.Format` only if they don't comply to the `java.text.MessageFormat` or `ParameterizedMessage` format. (#1223) * Split off async logger support into a new `log4j-async-logger` module. * Split off YAML configuration into a new `log4j-config-yaml` module. === Fixed * Rewrote message parameter formatter with improved escape handling (#1626) * The MongoDb4 appender now supports long values to configure `collectionSize` (#1747) * Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098) * Fix regression in `JdkMapAdapterStringMap` performance. (#2238) * Prevents ClassCastException when trying to assign a SimpleLoggerContext to a core LoggerContext (LOG4J2-1921) * Possible NullPointerException in MongoDb4DocumentObject, MongoDbDocumentObject, DefaultNoSqlObject. (LOG4J2-3392) * Fix NPE in `CloseableThreadContext`. (#1426) * Fix NPE in `RollingFileManager`. (#1645) * Fix `log4j-spring-cloud-config-client` dependencies to include only those required. (2157) * Workaround a Coursier/Ivy dependency resolution bug affecting `log4j-slf4j-impl` and `log4j-mongodb3`. (#2065) === Removed * Removed legacy `2.x` properties configuration factory. * Remove `DefaultLogEventFactory` * Remove `log4j-appserver` module (#2257) * Remove `org.apache.logging.log4j.core.parser` and related packages. (#2154) * Remove `log4j-jcl` module (#2257) * Removed JMX support. * Remove `log4j-layout-jackson` module (#2198) * Remove `log4j-layout-jackson-xml` module (#2198) * Remove `log4j2.enable.threadlocals` property (#2105) === Updated * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.1` (#2127) * Update `commons-codec:commons-codec` to version `1.16.1` (#2276) * Update `io.netty:netty-bom` to version `4.1.107.Final` (#2283) * Update `org.apache.logging:logging-parent` to version `10.6.0` (#2193) * Update `org.apache.tomcat:tomcat-juli` to version `10.1.18` (#2176) * Update `org.eclipse.jetty:jetty-bom` to version `9.4.54.v20240208` (#2285) * Update `org.jctools:jctools-core` to version `4.0.3` (#2267) * Update `org.slf4j:slf4j-api` to version `2.0.10` (#2136) * Update `org.springframework.boot:spring-boot-autoconfigure` to version `3.2.2` (#) * Update `org.springframework.cloud:spring-cloud-context` to version `4.1.1` (#2236) * Update `org.springframework:spring-framework-bom` to version `6.1.4` (#2294) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j Scala 13.1.0 released
Apache Log4j Scala team is pleased to announce the 13.1.0 release. This project provides a Scala-friendly interface to log against the Log4j API. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/scala === Release Notes This minor release contains a bug fix, Software Bill of Materials (SBOM) generation, and some dependency updates. Added * Start generating CycloneDX SBOM Fixed * Fix recursive inlining issues in Scala 3 macros (#40) Updated * Update `org.apache.logging.log4j:log4j-bom` to version `2.22.1` (#43) * Update `org.apache.logging:logging-parent` to version `10.6.0` (#44) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Async logger not logging after upgrading tomcat, jdk and log4j
Joan, On Fri, 26 Jan 2024 at 13:33, wrote: > Issue fixed. The problem was in the disruptor library, which we also migrated > from 3.4.4 to 4.0.0. Downgrading again to 3.4.4. fixed the problem. Thank you for sharing your solution with us. Since nobody was able to diagnose this problem from your status logs, I opened issue #2250[1] to add the correct log statements during the initialization of LMAX Disruptor. Note also, that the upcoming version 2.23.0 will support both LMAX Disruptor 3.x and 4.x (cf. issue #1829[2]), so you'll be able to upgrade to 4.x. As far as version 3.x of Log4j is concerned, our upcoming 3.0.0-beta2 will feature a separate `log4j-async-logger` artifact with a non-optional dependency on `com.lmax.disruptor:disruptor`[3]. We hope to relieve users from the burden of upgrading the Disruptor library themselves and rely on the transitive dependency in `log4j-async-logger`. Piotr [1] https://github.com/apache/logging-log4j2/issues/2250 [2] https://github.com/apache/logging-log4j2/issues/1829 [3] https://github.com/apache/logging-log4j2/pull/2241 - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: Async logger not logging after upgrading tomcat, jdk and log4j
Hi, Issue fixed. The problem was in the disruptor library, which we also migrated from 3.4.4 to 4.0.0. Downgrading again to 3.4.4. fixed the problem. Regards, Joan. -Original Message- From: Piotr P. Karwasz Sent: Thursday, January 25, 2024 1:20 PM To: Log4J Users List Subject: Re: Async logger not logging after upgrading tomcat, jdk and log4j Hi Joan, On Thu, 25 Jan 2024 at 12:06, wrote: > My application has been using async logging for years by setting this env > variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9: > -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncL > oggerContextSelector > > Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the > above variable set, nothing is logged. If I remove it then it starts to log > again, but without async. > > Is there any change I'm missing regarding this async logging when moving to > these new versions of tomcat, java and log4j? Can you test with `-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector` since `Log4jContextSelector` is deprecated since 2.10? Although it should have no influence on the context selector, if you were using `log4j-web`, did you switch to `log4j-jakarta-web`? Piotr ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: Async logger not logging after upgrading tomcat, jdk and log4j
'org.apache.logging.log4j2:type=55494dde,component=Loggers,name=*,subtype=RingBuffer' DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde,component=StatusLogger DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde,component=ContextSelector DEBUG StatusLogger Registering MBean org.apache.logging.log4j2:type=55494dde,component=Appenders,name=DefaultConsole-2 Joan. -Original Message- From: joan.balagu...@ventusproxy.com Sent: Thursday, January 25, 2024 1:56 PM To: 'Log4J Users List' Subject: RE: Async logger not logging after upgrading tomcat, jdk and log4j Hello, Here is the trace when starting tomcat with '-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector': https://gist.github.com/joanbalaguero/1fa286417bfc9dbd3ce75e043bd26f3d It seems the async contexts are started, but maybe someone can see something wrong that makes the log does not work. Thanks, Joan. - 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: Async logger not logging after upgrading tomcat, jdk and log4j
Hello, Here is the trace when starting tomcat with '-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector': https://gist.github.com/joanbalaguero/1fa286417bfc9dbd3ce75e043bd26f3d It seems the async contexts are started, but maybe someone can see something wrong that makes the log does not work. Thanks, Joan. - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
RE: Async logger not logging after upgrading tomcat, jdk and log4j
Hi Ganesh, I already have this 2.22.1. The war file contains the right libraries, all in version 2.22.1. Where can I see the supported tomcat/java versions depending on the log4j version? Thanks, Joan. -Original Message- From: Ganesh S Sent: Thursday, January 25, 2024 1:14 PM To: Log4J Users List Subject: Re: Async logger not logging after upgrading tomcat, jdk and log4j Hello, Check the dependency hierarchy, which version of log4j is being used. I had faced similar issue, even though if I specified some particular version of log4j, maven was not picking that particular version though there were no other dependencies which were using log4j at any nested level. For that I had added the below in the pom.xml file 2.22.1 After this also if it doesn't work pick the appropriate version of log4j which supports your version of Java and tomcat. On Thu, Jan 25, 2024, 4:35 PM wrote: > Hello, > > I would like to ask about this issue before starting to post debug logs. > > My application has been using async logging for years by setting this > env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9: > > -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncL > oggerContextSelector > > Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With > the above variable set, nothing is logged. If I remove it then it > starts to log again, but without async. > > Is there any change I'm missing regarding this async logging when > moving to these new versions of tomcat, java and log4j? > > Thanks, > > Joan. > > > ----- > 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: Async logger not logging after upgrading tomcat, jdk and log4j
Hi Piotr, I already did it ... no success. Thanks, Joan. -Original Message- From: Piotr P. Karwasz Sent: Thursday, January 25, 2024 1:20 PM To: Log4J Users List Subject: Re: Async logger not logging after upgrading tomcat, jdk and log4j Hi Joan, On Thu, 25 Jan 2024 at 12:06, wrote: > My application has been using async logging for years by setting this env > variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9: > -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncL > oggerContextSelector > > Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the > above variable set, nothing is logged. If I remove it then it starts to log > again, but without async. > > Is there any change I'm missing regarding this async logging when moving to > these new versions of tomcat, java and log4j? Can you test with `-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector` since `Log4jContextSelector` is deprecated since 2.10? Although it should have no influence on the context selector, if you were using `log4j-web`, did you switch to `log4j-jakarta-web`? Piotr ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org ----- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Async logger not logging after upgrading tomcat, jdk and log4j
Hi Joan, On Thu, 25 Jan 2024 at 12:06, wrote: > My application has been using async logging for years by setting this env > variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9: > -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector > > Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the > above variable set, nothing is logged. If I remove it then it starts to log > again, but without async. > > Is there any change I'm missing regarding this async logging when moving to > these new versions of tomcat, java and log4j? Can you test with `-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector` since `Log4jContextSelector` is deprecated since 2.10? Although it should have no influence on the context selector, if you were using `log4j-web`, did you switch to `log4j-jakarta-web`? Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Async logger not logging after upgrading tomcat, jdk and log4j
Hello, Check the dependency hierarchy, which version of log4j is being used. I had faced similar issue, even though if I specified some particular version of log4j, maven was not picking that particular version though there were no other dependencies which were using log4j at any nested level. For that I had added the below in the pom.xml file 2.22.1 After this also if it doesn't work pick the appropriate version of log4j which supports your version of Java and tomcat. On Thu, Jan 25, 2024, 4:35 PM wrote: > Hello, > > I would like to ask about this issue before starting to post debug logs. > > My application has been using async logging for years by setting this env > variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9: > > -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector > > Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the > above variable set, nothing is logged. If I remove it then it starts to log > again, but without async. > > Is there any change I'm missing regarding this async logging when moving > to these new versions of tomcat, java and log4j? > > Thanks, > > Joan. > > > ----- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
Async logger not logging after upgrading tomcat, jdk and log4j
Hello, I would like to ask about this issue before starting to post debug logs. My application has been using async logging for years by setting this env variable on tomcat 8.5.x running on java 11 with log4j-2.15/6/7/8/9: -DLog4jContextSelector=org.apache.logging.log4j.core.async.BasicAsyncLoggerContextSelector Now we have migrated to Tomcat 10.1.18, java 17 and log4j-2.22.1. With the above variable set, nothing is logged. If I remove it then it starts to log again, but without async. Is there any change I'm missing regarding this async logging when moving to these new versions of tomcat, java and log4j? Thanks, Joan. - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j Kotlin API 1.4.0 released
The Apache Log4j Kotlin API team is pleased to announce the 1.4.0 release. This project contains a Kotlin-friendly interface to log against the Log4j API. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/kotlin/ === Release Notes This minor release fixes incorrect coroutine context map and stack. Added * Started generating CycloneDX SBOM with the recent update of `logging-parent` to version `10.2.0` Changed * Coroutine context is not cleared properly, only appended to (#54) * Update `org.apache.logging:logging-parent` to version `10.2.0` * Update `org.apache.logging.log4j:log4j-bom` to version `2.22.0` (#52) * Update `org.apache.logging:logging-parent` to version `10.4.0` (#53) * Update `org.codehaus.mojo:build-helper-maven-plugin` to version `3.5.0` (#51) * Update `org.codehaus.mojo:exec-maven-plugin` to version `3.1.1` (#50) * Update `org.junit:junit-bom` to version `5.10.1` (#49) Apache Log4j Kotlin API team - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 2.22.1 released
The Apache Log4j team is pleased to announce the 2.22.1 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/ == Release Notes This release contains only dependency upgrades and bug fixes, which do not change the behavior of the artifacts. While maintaining compatibility with Java 8, the artifacts in this release where generated using JDK 17, unlike version `2.22.0` that used JDK 11. === Fixed * Mark `JdkMapAdapterStringMap` as frozen if map is immutable. (#2098) * Fix NPE in `CloseableThreadContext`. (#1426) * Use the module name of Conversant Media Disruptor from version `1.2.16+` of the library. * Fix NPE in `RollingFileManager`. (#1645) * Fix `log4j-to-slf4j` JPMS and OSGi descriptors. (#1983) * Workaround a Coursier/Ivy dependency resolution bug affecting `log4j-slf4j-impl` and `log4j-mongodb3`. (#2065) === Updated * Bumped the minimum Java version required for the build to Java 17. Runtime requirements remain unchanged. (#2021) * Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2030) * Update `com.google.guava:guava` to version `33.0.0-jre` (#2110) * Update `commons-codec:commons-codec` to version `1.16.0` (#2042) * Update `commons-io:commons-io` to version `2.15.1` (#2034) * Update `commons-logging:commons-logging` to version `1.3.0` (#2050) * Update `io.netty:netty-bom` to version `4.1.104.Final` (#2095) * Update `org.apache.commons:commons-compress` to version `1.25.0` (#2045) * Update `org.apache.commons:commons-dbcp2` to version `2.11.0` (#2048) * Update `org.apache.commons:commons-lang3` to version `3.14.0` (#2047) * Update `org.apache.commons:commons-pool2` to version `2.12.0` (#2057) * Update `org.apache.kafka:kafka-clients` to version `3.6.1` (#2068) * Update `org.apache.logging:logging-parent` to version `10.5.0` (#2119) * Update `org.jctools:jctools-core` to version `4.0.2` (#1984) * Update `org.springframework.boot:spring-boot` to version `2.7.18` (#1998) * Update `org.springframework.cloud:spring-cloud-dependencies` to version `2021.0.9` (#2109) Apache Log4j Team - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 3.0.0-beta1 released
Apache Log4j team is pleased to announce the 3.0.0-beta1 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/3.x == Release Notes This is the first beta release of the upcoming major release, i.e., `3.0.0`. === Added * Add annotations for nullability. (LOG4J2-1477) * Remove deprecated code. (LOG4J2-2493) * Add a more generalized dependency injection system to plugins inspired by JSR 330. (LOG4J2-2803) * Add and enhance structured properties for per-context settings outside configuration files. (LOG4J2-3299[LOG4J2-3299], #1473) * Automate artifact publishing and release preparation. (LOG4J2-3466) * Add support for dependency injection of plugins into container types such as `Optional`, `Collection`, `Set`, `Stream`, `List`, and `Map`. (LOG4J2-3496) * Add support for `ConstraintValidator` in plugin classes. (LOG4J2-3497) === Changed * Remove liquibase-log4j2 maven module (#1193) * Make the output of annotation processing reproducible. (#1520) * Replace `synchronized` blocks with locks for improved performance with virtual threads. (#1532) * Removes additional `isFiltered` checks in `AsyncLoggerConfig`. (#1550) * Ignore exceptions thrown by PropertySources. Eliminate ClassCastException when SimpleLoggerContext is used. (spring-projects/spring-boot#33450, #1799) * Update `com.lmax:disruptor` to version `4.0.0` (#1829) * Migrate most tests to JUnit 5. This includes a more powerful set of test extensions. (LOG4J2-2653) * Make Log4j use its own BOM. (LOG4J2-3511) * Change encoding of HTTP Basic Authentication to UTF-8. (#1970) * Upgraded the required compiler version to Java 17 * Upgraded the required runtime version to Java 17 * Update `actions/checkout` to version `4.1.1` (#1869) * Update `actions/setup-java` to version `3.13.0` (#1809) * Update `actions/setup-python` to version `4.7.1` (#1831) * Update `ch.qos.logback:logback-classic` to version `1.4.14` (#2028) * Update `com.datastax.cassandra:cassandra-driver-core` to version `3.11.5` (#1889) * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.0` (#1974) * Update `com.github.luben:zstd-jni` to version `1.5.5-11` (#2032) * Update `com.github.spotbugs:spotbugs-maven-plugin` to version `4.7.3.6` (#1879) * Update `com.github.tomakehurst:wiremock-jre8` to version `2.35.1` (#1765) * Update `com.google.code.java-allocation-instrumenter:java-allocation-instrumenter` to version `3.3.4` (#2102) * Update `com.google.errorprone:error_prone_core` to version `2.23.0` (#1871) * Update `com.google.guava:guava-testlib` to version `32.1.3-jre` (#1934) * Update `com.h2database:h2` to version `2.2.224` (#1917) * Update `commons-codec:commons-codec` to version `1.16.0` (#2054) * Update `commons-io:commons-io` to version `2.15.1` (#2035) * Update `commons-logging:commons-logging` to version `1.3.0` (#2046) * Update `de.flapdoodle.reverse:de.flapdoodle.reverse` to version `1.7.2` (#2000) * Update `io.netty:netty-bom` to version `4.1.104.Final` (#2097) * Update `net.java.dev.jna:jna` to version `5.14.0` (#2082) * Update `org.apache.aries.spifly:org.apache.aries.spifly.dynamic.bundle` to version `1.3.7` (#2053) * Update `org.apache.commons:commons-compress` to version `1.25.0` (#2055) * Update `org.apache.commons:commons-csv` to version `1.10.0` (#2041) * Update `org.apache.commons:commons-dbcp2` to version `2.11.0` (#2044) * Update `org.apache.commons:commons-lang3` to version `3.14.0` (#2036) * Update `org.apache.commons:commons-pool2` to version `2.12.0` (#2038) * Update `org.apache.groovy:groovy-bom` to version `4.0.16` (#2039) * Update `org.apache.maven:maven-core` to version `3.9.6` (#2049) * Update `org.apache.maven.surefire:surefire-junit47` to version `3.2.3` (#2091) * Update `org.apache.tomcat:tomcat-juli` to version `10.1.17` (#2086) * Update `org.codehaus.plexus:plexus-utils` to version `3.5.1` (#2061) * Update `org.eclipse.jetty:jetty-bom` to version `9.4.53.v20231009` (#1931) * Update `org.eclipse.persistence:org.eclipse.persistence.jpa` to version `2.7.13` (#1933) * Update `org.eclipse.platform:org.eclipse.osgi` to version `3.18.600` (#2064) * Update `org.elasticsearch.client:elasticsearch-rest-high-level-client` to version `7.17.16` (#2085) * Update `org.graalvm.truffle:truffle-api` to version `23.1.1` (#1872) * Update `org.jctools:jctools-core` to version `4.0.2` (#1995) * Update `org.jmdns:jmdns` to version `3.5.9` (#2069) * Update `org.junit:junit-bom` to version `5.10.1` (#1993) * Update `org.junit-pioneer:junit-pioneer` to version `2.2.0` (#1986) * Update `org.mockito:mockito-bom` to version `5.8.0` (#2031) * Update `org.mongodb:bson` to version `4.11.1` (#1991) * Update `org.springframework.boot:spring-boot` to version `2.7.17` (#1902) * Update `org.springframework.boot:spring-boot-dependencies
[ANNOUNCE] Apache Log4j Tools 0.7.0 released
Apache Log4j Tools team is pleased to announce the 0.7.0 release. This project provides tooling internally used by the Apache Log4j project. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/tools === Release Notes This minor release contains various bug fixes and improvements. Added * Add the new `updated` changelog entry type and bump the XSD version to `0.1.3` Changed * Update `commons-io:commons-io` to version `2.15.1` (#86) * Update `org.apache.maven.plugin-tools:maven-plugin-annotations` to version `3.10.2` (#87) Fixed * Sort changelog entry types alphanumerically * Fix `log4j-changelog:release` failure on empty unreleased changelog directory (#90) * Fix parsing of patch versions in `log4j-changelog:release` goal (#89)
[ANNOUNCE] Apache Log4j Tools 0.6.0 released
The Apache Log4j Tools team is pleased to announce the 0.6.0 release. This project provides tooling internally used by the Apache Log4j project. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/tools === Release Notes This minor release contains various bug fixes and improvements. Added * Started generating CycloneDX SBOM with the recent update of `logging-parent` to version `10.4.0` Changed * Update `org.apache.logging:logging-parent` to version `10.4.0` Fixed * `log4j-tools-bom` was broken due to removed `parent` during flattening. This is automatically fixed by the recent `logging-parent` version `10.4.0` update. - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j JMX GUI 2.22.0 released
Apache Log4j JMX GUI[1] team is pleased to announce the 2.22.0 release. This project provides a Swing-based client for remotely editing the Log4j configuration and remotely monitoring `StatusLogger` output. It can be run as a standalone application or as a JConsole plugin. [1] https://logging.apache.org/log4j/jmx-gui == Release notes This release contains minor improvements. === Added * Started generating CycloneDX SBOM with the recent update of `logging-parent` to version `10.4.0` * Publish the website[1] === Changed * Add OSGi and JPMS descriptors * Update `log4j-core` to version `2.21.1` * Update `logging-parent` to version `10.4.0` === Fixed * Restore the original Maven `groupId`: `org.apache.logging.log4j` - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 2.22.0 released
The Apache Log4j team is pleased to announce the 2.22.0 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j == Release notes This release provides a CycloneDX Software Bill of Materials (SBOM)[2] along with each artifact and contains bug fixes addressing issues in the JPMS & OSGi infrastructure overhauled in `2.21.0`, dependency updates, and some other minor fixes and improvements. [2] https://cyclonedx.org/capabilities/sbom === CycloneDX Software Bill of Materials (SBOM) This is the first Log4j release that provides a CycloneDX Software Bill of Materials (SBOM)[2] along with each artifact. Generated SBOMs are attached as artifacts with `cyclonedx` classifier and XML extensions, that is, `--cyclonedx.xml`. They contain `vulnerability-assertion` references to a CycloneDX Vulnerability Disclosure Report (VDR)[3] that Apache Logging Services uses for all projects it maintains. This VDR is accessible through the following URL: https://logging.apache.org/cyclonedx/vdr.xml SBOM generation is streamlined by `logging-parent`, see its website[4] for details. [3] https://cyclonedx.org/capabilities/vdr [4] https://logging.apache.org/logging-parent/latest/#cyclonedx-sbom === Changed * Change the order of evaluation of `FormattedMessage` formatters. Messages are evaluated using `java.util.Format` only if they don't comply to the `java.text.MessageFormat` or `ParameterizedMessage` format. (#1223) * Change default encoding of HTTP Basic Authentication to UTF-8 and add `log4j2.configurationAuthorizationEncoding` property to overwrite it. (#1970) * Update `com.fasterxml.jackson:jackson-bom` to version `2.16.0` (#1974) * Update `com.github.luben:zstd-jni` to version `1.5.5-10` (#1940) * Update `com.google.guava:guava` to version `32.1.3-jre` (#1875) * Update `io.netty:netty-bom` to version `4.1.101.Final` (#1960) * Update `org.eclipse.persistence:org.eclipse.persistence.jpa` to version `2.7.13` (#1900) * Update `org.fusesource.jansi:jansi` to version `2.4.1` (#1907) * Update `org.mongodb:bson` to version `4.11.1` (#1957) * Update `org.springframework:spring-framework-bom` to version `5.3.30` * Update `org.springframework.boot:spring-boot` to version `2.7.17` (#1874) * Update `org.springframework:spring-framework-bom` to version `5.3.31` (#1973) * Update `org.zeromq:jeromq` to version `0.5.4` (#1878) === Removed * Removed unused `FastDateParser` which was causing unnecessary heap overhead (LOG4J2-3672, #1848) === Fixed * Fix MDC pattern converter causing issues for `%notEmpty` (#1922) * Export missing OSGi & JPMS modules in `log4j-layout-template-json` and `log4j-1.2-api` (#1895) * Fix `spring-test` dependency scope change (LOG4J2-3675) * Fix JPMS descriptors causing `jlink` issues (#1896) * Add missing `Implementation-` and `Specification-` entries to `MANIFEST.MF` (implemented by `logging-parent` version `10.3.0` update) (#1923) * Fix `NotSerializableException` thrown when `Logger` is serialized with a `ReusableMessageFactory` (#1884) - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: [ANNOUNCE] Log4j module deprecation
On Mon, 6 Nov 2023 at 23:14, Piotr P. Karwasz wrote: > > In order to concentrate our limited resources on the remaining modules, > the PMC decided to deprecate the following modules/features in 2.x and > to remove them in 3.x: > * `log4j-cassandra`, > * CouchDB appender, > * GELF appender, > * Kafka appender, > * jeroMQ appender, > * `log4j-jpa`, > * `log4j-mongodb3`, > * `log4j-spring-boot`, > * Java EE SMTP appender, > * `log4j-taglib`. Correction: this list should also include JsonLayout (replaced by JsonTemplateLayout) and YamlLayout. Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Log4j module deprecation
In order to concentrate our limited resources on the remaining modules, the PMC decided to deprecate the following modules/features in 2.x and to remove them in 3.x: * `log4j-cassandra`, * CouchDB appender, * GELF appender, * Kafka appender, * jeroMQ appender, * `log4j-jpa`, * `log4j-mongodb3`, * `log4j-spring-boot`, * Java EE SMTP appender, * `log4j-taglib`. Each of these modules either has a valid (and maintained) third-party alternative or its usage has been deemed irrelevant. Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Log4j module deprecation
Hi all, On Thu, 28 Sept 2023 at 09:35, Piotr P. Karwasz wrote: > We know that statistics are not everything and that is why we would > like to hear your opinion on these modules. The discussion will be > open for a month, after which the PMC will announce a definitive list > of deprecations. It has been more than a month since I sent the announcement. I'll prepare an e-mail and submit it to `dev` for a vote. Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j 2.21.1 released
Apache Log4j team is pleased to announce the 2.21.1 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j == Release Notes This patch release contains only the fix of a `log4j-jcl` bug that prevents it from connecting with `commons-logging`. The Log4j 2.21.1 API, as well as the other artifacts, maintains binary compatibility with the previous release. Apache Log4j 2.21.1 requires Java 8 to run. The build requires JDK 11 and generates reproducible binaries. For complete information on Apache Log4j 2, including instructions on how to submit bug reports, patches, get support, or suggestions for improvement, see the Apache Log4j 2.x website[2]. [2] http://logging.apache.org/log4j/2.x/ === Fixed * Fixes the Apache Commons Logging (JCL) bridge: `log4j-jcl`. (#1865) Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: [ANNOUNCE] Apache Log4j 2.21.0 released
I got hit at work with the loss of log4j-jmx-gui. Is log4j-jmx-gui 2.20.0 compatible with log4j 2.21.0? Gary On Mon, Oct 16, 2023, 5:59 PM Gary Gregory wrote: > Thank you for RM'ing Christian! > > Gary > > > > On Mon, Oct 16, 2023, 4:28 PM Christian Grobmeier > wrote: > >> Apache Log4j team is pleased to announce the 2.21.0 >> release. Apache Log4j is a versatile, industrial-strength >> Java logging framework composed of an API, its implementation, >> and components to assist the deployment for various use cases. >> For further information (support, download, etc.) see the project >> website[1]. >> >> [1] https://logging.apache.org/log4j >> >> == Release Notes >> >> This release primarily focuses on enhancements to our OSGi and JPMS >> support and contains several bug fixes. >> It will be the first release built and signed by the CI using the >> https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0=index[ASF >> Logging Services Release Manager GPG key], which is shared in >> https://www.apache.org/dist/logging/KEYS[KEYS]. >> >> The Log4j 2.21.0 API, as well as the other artifacts, maintains binary >> compatibility with the previous release. >> >> Apache Log4j 2.21.0 requires Java 8 to run. >> The build requires JDK 11 and generates reproducible binaries. >> >> For complete information on Apache Log4j 2, including instructions on how >> to submit bug reports, patches, get support, or suggestions for >> improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 >> website]. >> >> === OSGi changes >> >> All the published artifacts are OSGi bundles or fragments. >> >> This release introduces a change in the bundle symbolic names to allow >> them to function as JPMS module name: all hyphens `-` present in the bundle >> names of previous releases were replaced by dots `.`. >> >> === JPMS changes >> >> All the published artifacts have been migrated from automatic modules to >> named JPMS modules. >> All packages marked as private in the Javadoc are not exported. >> >> The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, >> `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the >> same convention as the OSGi bundle names. >> >> === Added >> >> * Added marker parent support to `JsonTemplateLayout` (#1381) >> * Added https://facebook.github.io/zstd/[ZStandard compression] support >> (#1508, #1514) >> * Added a warning for incorrect syntax of highlighting styles (#1545, >> #1637) >> >> === Changed >> >> * Open `FileExtension` methods to allow their usage in custom >> ``RolloverStrategy``s (#1365, #1683) >> * Bumped the minimum Java version required for the build to JDK 11. >> Runtime requirements remain unchanged. (#1369) >> * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to >> `OFF` and `ALL`, respectively (#1503) >> * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) >> * Use Java version-specific warnings in `StackLocator` (#1760) >> * Started logging a status error event instead of an NPE in >> `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has >> no valid `BundleContext` for a service type >> * Implemented a CI-based release process >> * Update Eclipse Angus Activation to version >> https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] >> (#1591) >> * Update Eclipse Angus Mail to version >> https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] >> (#1591) >> * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 >> (#1591) >> * Update Apache Cassandra to version >> https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] >> (#1591) >> * Update Apache Commons Compress to version >> https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] >> (#1591) >> * Update Apache Commons CSV to version >> https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] >> (#1591) >> * Update Jackson to version >> https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] >> (#1591) >> * Update Jakarta Activation API to version >> https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] >> (#1591) >> * Update Jakarta Mail API to version >> https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) >> * Update JCTools to version >
Re: [ANNOUNCE] Apache Log4j 2.21.0 released
Thank you for RM'ing Christian! Gary On Mon, Oct 16, 2023, 4:28 PM Christian Grobmeier wrote: > Apache Log4j team is pleased to announce the 2.21.0 > release. Apache Log4j is a versatile, industrial-strength > Java logging framework composed of an API, its implementation, > and components to assist the deployment for various use cases. > For further information (support, download, etc.) see the project > website[1]. > > [1] https://logging.apache.org/log4j > > == Release Notes > > This release primarily focuses on enhancements to our OSGi and JPMS > support and contains several bug fixes. > It will be the first release built and signed by the CI using the > https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0=index[ASF > Logging Services Release Manager GPG key], which is shared in > https://www.apache.org/dist/logging/KEYS[KEYS]. > > The Log4j 2.21.0 API, as well as the other artifacts, maintains binary > compatibility with the previous release. > > Apache Log4j 2.21.0 requires Java 8 to run. > The build requires JDK 11 and generates reproducible binaries. > > For complete information on Apache Log4j 2, including instructions on how > to submit bug reports, patches, get support, or suggestions for > improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 > website]. > > === OSGi changes > > All the published artifacts are OSGi bundles or fragments. > > This release introduces a change in the bundle symbolic names to allow > them to function as JPMS module name: all hyphens `-` present in the bundle > names of previous releases were replaced by dots `.`. > > === JPMS changes > > All the published artifacts have been migrated from automatic modules to > named JPMS modules. > All packages marked as private in the Javadoc are not exported. > > The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, > `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the > same convention as the OSGi bundle names. > > === Added > > * Added marker parent support to `JsonTemplateLayout` (#1381) > * Added https://facebook.github.io/zstd/[ZStandard compression] support > (#1508, #1514) > * Added a warning for incorrect syntax of highlighting styles (#1545, > #1637) > > === Changed > > * Open `FileExtension` methods to allow their usage in custom > ``RolloverStrategy``s (#1365, #1683) > * Bumped the minimum Java version required for the build to JDK 11. > Runtime requirements remain unchanged. (#1369) > * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` > and `ALL`, respectively (#1503) > * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) > * Use Java version-specific warnings in `StackLocator` (#1760) > * Started logging a status error event instead of an NPE in > `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has > no valid `BundleContext` for a service type > * Implemented a CI-based release process > * Update Eclipse Angus Activation to version > https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] > (#1591) > * Update Eclipse Angus Mail to version > https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] > (#1591) > * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 > (#1591) > * Update Apache Cassandra to version > https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] > (#1591) > * Update Apache Commons Compress to version > https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] > (#1591) > * Update Apache Commons CSV to version > https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] > (#1591) > * Update Jackson to version > https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] > (#1591) > * Update Jakarta Activation API to version > https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591) > * Update Jakarta Mail API to version > https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) > * Update JCTools to version > https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] > (#1591) > * Update Apache Kafka to version > https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] > (#1591) > * Update Kubernetes client to version > https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4] > (#1591) > * Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591) > * Update `io.netty:netty-bom` to version 4.1.97 (#1591) > * Update Spring Boot to version > https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.
[ANNOUNCE] Apache Log4j 2.21.0 released
Apache Log4j team is pleased to announce the 2.21.0 release. Apache Log4j is a versatile, industrial-strength Java logging framework composed of an API, its implementation, and components to assist the deployment for various use cases. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j == Release Notes This release primarily focuses on enhancements to our OSGi and JPMS support and contains several bug fixes. It will be the first release built and signed by the CI using the https://keyserver.ubuntu.com/pks/lookup?search=077E8893A6DCC33DD4A4D5B256E73BA9A0B592D0=index[ASF Logging Services Release Manager GPG key], which is shared in https://www.apache.org/dist/logging/KEYS[KEYS]. The Log4j 2.21.0 API, as well as the other artifacts, maintains binary compatibility with the previous release. Apache Log4j 2.21.0 requires Java 8 to run. The build requires JDK 11 and generates reproducible binaries. For complete information on Apache Log4j 2, including instructions on how to submit bug reports, patches, get support, or suggestions for improvement, see http://logging.apache.org/log4j/2.x/[the Apache Log4j 2 website]. === OSGi changes All the published artifacts are OSGi bundles or fragments. This release introduces a change in the bundle symbolic names to allow them to function as JPMS module name: all hyphens `-` present in the bundle names of previous releases were replaced by dots `.`. === JPMS changes All the published artifacts have been migrated from automatic modules to named JPMS modules. All packages marked as private in the Javadoc are not exported. The module name of four bridges (`log4j-slf4j-impl`, `log4j-slf4j2-impl`, `log4j-to-jul` and `log4j-to-slf4j`) have been changed to adhere to the same convention as the OSGi bundle names. === Added * Added marker parent support to `JsonTemplateLayout` (#1381) * Added https://facebook.github.io/zstd/[ZStandard compression] support (#1508, #1514) * Added a warning for incorrect syntax of highlighting styles (#1545, #1637) === Changed * Open `FileExtension` methods to allow their usage in custom ``RolloverStrategy``s (#1365, #1683) * Bumped the minimum Java version required for the build to JDK 11. Runtime requirements remain unchanged. (#1369) * Set the default `minLevel` and `maxLevel` of `LevelRangeFilter` to `OFF` and `ALL`, respectively (#1503) * Removed additional `isFiltered` checks in `AsyncLoggerConfig` (#1550) * Use Java version-specific warnings in `StackLocator` (#1760) * Started logging a status error event instead of an NPE in `OsgiServiceLocator.loadServices(Class, Lookup, boolean)` when a bundle has no valid `BundleContext` for a service type * Implemented a CI-based release process * Update Eclipse Angus Activation to version https://github.com/eclipse-ee4j/angus-activation/releases/tag/2.0.1[2.0.1] (#1591) * Update Eclipse Angus Mail to version https://github.com/eclipse-ee4j/angus-mail/releases/tag/2.0.2[2.0.2] (#1591) * Update `com.datastax.cassandra:cassandra-driver-core` to version 3.11.5 (#1591) * Update Apache Cassandra to version https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt[3.11.16] (#1591) * Update Apache Commons Compress to version https://commons.apache.org/proper/commons-compress/changes-report.html#a1.24.0[1.24.0] (#1591) * Update Apache Commons CSV to version https://commons.apache.org/proper/commons-csv/changes-report.html#a1.10.0[1.10.0] (#1591) * Update Jackson to version https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15.2[2.15.2] (#1591) * Update Jakarta Activation API to version https://jakarta.ee/specifications/activation/2.1/changelog/[2.1.2] (#1591) * Update Jakarta Mail API to version https://jakarta.ee/specifications/mail/2.1/changelog/[2.1.2] (#1591) * Update JCTools to version https://github.com/JCTools/JCTools/blob/master/RELEASE-NOTES.md[4.0.1] (#1591) * Update Apache Kafka to version https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html[3.4.0] (#1591) * Update Kubernetes client to version https://github.com/fabric8io/kubernetes-client/releases?q=5.12.4[5.12.4] (#1591) * Update `org.mongodb:mongodb-driver-core` to version 4.10.2 (#1591) * Update `io.netty:netty-bom` to version 4.1.97 (#1591) * Update Spring Boot to version https://github.com/spring-projects/spring-boot/releases/tag/v2.7.15[2.7.15] (#1591) * Update Spring Framework to version https://github.com/spring-projects/spring-framework/releases/tag/v5.3.29[5.3.29] (#1591) * Update Tomcat JULI to version 10.0.27 (#1591) * Update Woodstox to version https://github.com/FasterXML/woodstox/blob/master/release-notes/VERSION[6.5.1] (#1591) === Removed * Moved `log4j-jmx-gui` to https://github.com/apache/logging-log4j-jmx-gui/actions[its own repository] along with its own release cycle === Fixed * Added validation to rolling file manager path conditions (#1231) * Adapted the OSGi metadata of `log4j
[ANNOUNCE] Apache Log4j Scala 13.0.0 released
Apache Log4j Scala team is pleased to announce the 13.0.0 release. This project provides a Scala-friendly interface to log against the Log4j API. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/scala === Release Notes The highlights of this major release are Scala 3 support, JPMS descriptors, and the switch to semantic versioning[2]. [2] https://semver.org Note that this release is still binary backward compatible with the earlier release `12.0`. Though we needed to bump the major version number for the semantic versioning switch to avoid the confusion related with version ordering. Added * Added support for Scala 3 (LOG4J2-3184, #26) * Added OSGi and JPMS support Changed * Bumped the Java version to 17 (Scala 2.10 and 2.11 targets still require Java 8 that build switches to using `maven-toolchains-plugin`) * Switch the CI to GitHub Actions * Switched from `sbt` to Maven to take advantage of `logging-parent` conveniences * Switched to semantic versioning * Updated `org.apache.logging.log4j:log4j-api` version to `2.20.0` * Update `org.apache.logging:logging-parent` to version `10.1.1` * Started using `log4j-changelog` - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
[ANNOUNCE] Apache Log4j Kotlin API 1.3.0 released
Apache Log4j Kotlin API team is pleased to announce the 1.3.0 release. This project contains a Kotlin-friendly interface to log against the Log4j API. For further information (support, download, etc.) see the project website[1]. [1] https://logging.apache.org/log4j/kotlin === Release Notes This minor release bumps the Kotlin baseline to 1.6.21 and contains various small improvements. Added * Added an extension property for storing a cached logger (#29) * Added facade APIs for manipulating the context map and stack (#30) * Added missing `catching` and `throwing` API methods in `KotlinLogger` (#32) * Added JPMS support and used `org.apache.logging.log4j.api.kotlin` for the module name Changed * Updated Log4j dependency to `2.20.0` * Bumped `logging-parent` version to `10.1.1` and overhauled the entire project infrastructure to take advantage of its goodies (#37) * Renamed OSGi `Bundle-SymbolicName` from `org.apache.logging.log4j.kotlin` to `org.apache.logging.log4j.api.kotlin` * Migrated tests to JUnit 5 * Bumped Kotlin and Kotlin Extensions baseline to `1.6.21` and `1.6.4` respectively * Skipped deploying `log4j-api-kotlin-benchmark` and `log4j-api-kotlin-sample` modules Removed * Stopped exporting KDoc to HTML - 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
On Fri, Sep 29, 2023, at 21:40, Ralph Goers wrote: > 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”. I see. Well, I got a different impression when re-reading the discussion, I was also thinking this deprecation plan stands. The text was shared before it was sent here, too. I would have expected a -1 at least then. Btw, I was responding to you because yours was the last e-mail in my client only > > > 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
Re: Log4j module deprecation
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
>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 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 - 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
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: Log4j module deprecation
* For the Cassandra appender, I’m ok with deprecation. I had added this plugin a while back partly as a demo to show how to write plugins and for some consulting-related use cases, but I haven’t used this in quite some time as I’d lean toward some form of queue middleware between logs and a Cassandra sink. * For the Kafka appender, while I like this appender due to the potential for supporting asynchronous appender APIs, this is another thing that I’d also end up separating in practice, but that’s mainly due to moving that piece of a logging pipeline into a log collector of some sort (e.g., via Fluentbit) * Same with the ZeroMQ appender. While I love ZeroMQ as a library and general piece of tech, it works best with more end-to-end code; I’m not sure how useful it is to have only one end implemented here. At best, this plugin is more of a sample. * The SMTP appender, on the other hand, seems like a potentially useful one to continue supporting. After all, all software eventually learns how to send email! * JNDI stuff seems like it could be useful for proprietary software integration. While I haven’t dealt with JNDI for this in several years, it was common to use JNDI to get references to various resources in a Java EE server to the various proprietary modules you’ve configured there (like message queues, database connections, other resource connections, and so forth) I don’t have much to say about the others. > On Sep 28, 2023, at 2: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: Log4j module deprecation
Thanks so much for the feedback Wayne, we really appreciate it. I couldn't follow what you mean with "Java wrappers". Could you elaborate on it, please? Could you give some concrete examples? What was missing? What did you implement? What does it have to do with JNDI and logging? On Thu, Sep 28, 2023 at 2:39 PM Wayne Cannon wrote: > > Volkan, > > A vote to retain JNDI-related features. > > Although I don't use JNDI regularly, I have used it several times in the last > decade for a Fortune 100 company to create Java wrappers when commercial > libraries don't provide a Java interface -- most recently for a commercial > product using one of the most popular license-management packages in use > today. > > --Wayne > > On Sep 28, 2023, 02:05, at 02:05, "Volkan Yazıcı" wrote: > >I have cross-posted this to GitHub Discussions > ><https://github.com/apache/logging-log4j2/discussions/1822> too. Feel > >free > >to participate there, if that is of your preference. > > > > > >On Thu, Sep 28, 2023 at 9: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: Log4j module deprecation
Volkan, A vote to retain JNDI-related features. Although I don't use JNDI regularly, I have used it several times in the last decade for a Fortune 100 company to create Java wrappers when commercial libraries don't provide a Java interface -- most recently for a commercial product using one of the most popular license-management packages in use today. --Wayne On Sep 28, 2023, 02:05, at 02:05, "Volkan Yazıcı" wrote: >I have cross-posted this to GitHub Discussions ><https://github.com/apache/logging-log4j2/discussions/1822> too. Feel >free >to participate there, if that is of your preference. > > >On Thu, Sep 28, 2023 at 9: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 >> >>
Re: Log4j module deprecation
I have cross-posted this to GitHub Discussions <https://github.com/apache/logging-log4j2/discussions/1822> too. Feel free to participate there, if that is of your preference. On Thu, Sep 28, 2023 at 9: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 > >
Log4j module deprecation
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
[ANNOUNCE] Apache Log4j JMX GUI 2.21.0 released
Apache Log4j JMX GUI[1] team is pleased to announce the 2.21.0 release. This project provides a Swing-based client for remotely editing the Log4j configuration and remotely monitoring `StatusLogger` output. It can be run as a standalone application or as a JConsole plugin. # Release Notes This marks the first release where the Log4j JMX GUI is released separately from the Log4j itself. ## Changes ### Added * Project is moved to a new repository[1] with its own release cycle [1] https://github.com/apache/logging-log4j-jmx-gui - 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
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: Facing issue in while doing migration log4j 1.x to 2.x
“JMSQueue” is an alias for the “JMS” plugin. Historically, the JMSQueue and JMSTopic plugins were separate, but that was before the JMS API was updated to allow for using the same classes for queues and topics. I unified the plugins a while ago and kept the aliases in place. > On Jun 6, 2023, at 12:52 AM, Piotr P. Karwasz wrote: > > Hi Nishu, > Sorry for the delay, > > On Wed, 24 May 2023 at 06:47, Nishu Gupta > wrote:> I did the set the `log4j1.compatibility` to `true` in the > custom properties. >> >> Do I need to use the log4j.xml while using the bridge jar? or I need to >> convert to log4j2.xml as well? > > My rule of thumb on this is for developers to use a `log4j2.xml` > configuration and leave to end users the possibility of using a > `log4j.xml`. > Converting from a restrictive Log4j 1.x configuration file to the more > powerful Log4j 2.x format is a one-time job. Unless you need custom > legacy components I don't see a reason not to do it. > > On Wed, 31 May 2023 at 13:27, Nishu Gupta wrote: >> Here is the log4j and lo4j2 xml. >> >> I need a help for how jms call trigger? >> >> > class="com.aba.package.MyProject" >> provideUrl="abcde://abc.test.com:3226" >> initialContextFactory="com.abc.naming.abcdeInitialContextFactory" >> queueConnectionFactoryBindingName="abc.def.qwe.ms" >> queueBinding="anc.def.create" >> messageOnly="true" >> username="abc" >> password="abc"> >> >> >> > threshold="INFO" >> provideUrl="abcde://abc.test.com:3226" >> initialContextFactory="com.abc.naming.abcdeInitialContextFactory" >> queueConnectionFactoryBindingName="abc.def.qwe.ms" >> queueBinding="anc.def.create" >> messageOnly="true" >> username="xyz" >> password="xyz" >> queueDeliveryMode="2"> >> > > I am not an expert on JMS, but your configuration has many errors: > > * there is **no** "JMSQueue" plugin, > * you use a lot of properties that do not exist (cf. > https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender > ). E.g. `initialContextFactory` should be `factoryName`, `provideUrl` > should be `providerURL` and so on. > > Piotr > > - > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Facing issue in while doing migration log4j 1.x to 2.x
Hi Nishu, Sorry for the delay, On Wed, 24 May 2023 at 06:47, Nishu Gupta wrote:> I did the set the `log4j1.compatibility` to `true` in the custom properties. > > Do I need to use the log4j.xml while using the bridge jar? or I need to > convert to log4j2.xml as well? My rule of thumb on this is for developers to use a `log4j2.xml` configuration and leave to end users the possibility of using a `log4j.xml`. Converting from a restrictive Log4j 1.x configuration file to the more powerful Log4j 2.x format is a one-time job. Unless you need custom legacy components I don't see a reason not to do it. On Wed, 31 May 2023 at 13:27, Nishu Gupta wrote: > Here is the log4j and lo4j2 xml. > > I need a help for how jms call trigger? > > class="com.aba.package.MyProject" > provideUrl="abcde://abc.test.com:3226" > initialContextFactory="com.abc.naming.abcdeInitialContextFactory" > queueConnectionFactoryBindingName="abc.def.qwe.ms" > queueBinding="anc.def.create" > messageOnly="true" > username="abc" > password="abc"> > > >threshold="INFO" > provideUrl="abcde://abc.test.com:3226" > initialContextFactory="com.abc.naming.abcdeInitialContextFactory" > queueConnectionFactoryBindingName="abc.def.qwe.ms" > queueBinding="anc.def.create" > messageOnly="true" > username="xyz" > password="xyz" > queueDeliveryMode="2"> > I am not an expert on JMS, but your configuration has many errors: * there is **no** "JMSQueue" plugin, * you use a lot of properties that do not exist (cf. https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender ). E.g. `initialContextFactory` should be `factoryName`, `provideUrl` should be `providerURL` and so on. Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: how to use log4j-to-jul with log4j-web
Hi All:
Thank you all for your help and the good information about log4j-web and
log4-core.
I already had my per-application logging configured in
WEB-INF/logging.properties and all output is going to the same log file
now that I've switched to log4j-to-jul.
Cheers,
Jason
On 6/2/2023 2:13 PM, Jason Guild wrote:
CAUTION: This email originated from outside the State of Alaska mail
system. Do not click links or open attachments unless you recognize
the sender and know the content is safe.
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
--
Jason Guild
Systems Programmer
Alaska Department of Transportation & Public Facilities
Statewide Administrative Services
820 E. 15th Ave.
Anchorage, Alaska 99501
Re: how to use log4j-to-jul with log4j-web
Hi Jason,
On Sat, 3 Jun 2023 at 00:13, Jason Guild wrote:
> The application currently uses log4j-web to get the all the essential
> setup for initializing log4j 2 under an application container. The
> log4j-web library appears to have a hard dependency on log4j-core.
The `log4j-web` module is only useful to initialize the `log4j-core`
implementation of the Log4j 2.x API. If you don't use `log4j-core` you
don't need it.
On Sat, 3 Jun 2023 at 02:23, Ralph Goers wrote:
>
> When using log4j-to-jul you cannot use ANY other log4j modules except for
> log4j-api. You must configure Tomcat’s logging to handle all the logging for
> your application.
That is a little bit oversimplified. There are a lot of Log4j modules:
* some like `log4j-layout-template-json` or `log4j-web` contain
components for `log4j-core`. These can not be used with
`log4j-to-jul`.
* other modules contain adapters from framework X to Log4j 2.x API
(e.g. `log4j-slf4j-impl`) or depend only on the Log4j 2.x API (e.g.
`log4j-iostreams`). These can be used with `log4j-to-jul`.
At work we use `log4j-api` + `log4j-to-jul` for all application
logging together with:
* `log4j-slf4j-impl` (the dependency on `log4j-core` is just for the
comfort of most users and can be safely excluded), `log4j-jcl` and
`log4j-iostreams` to forward everything other logging framework to
Log4j 2.x API,
* a `WEB-INF/classes/logging.properties` file that provides
per-application configuration (using the standard
ClassLoaderLogManager JUL implementation shipped with Tomcat). The
`${classloader.webappName}` variable comes very handy here.
Logging is not very important for our clients and this limits our
responsibility in case of problems with `log4j-core`.
Obviously this is hardly a useful setup during development and tests,
so our test machines use my Log4j extensions[1] to delegate all Log4j
2.x API calls to a `log4j-core` installation in Tomcat's system
classloader.
Piotr
[1] https://github.com/copernik-eu/log4j-plugins
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: how to use log4j-to-jul with log4j-web
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
how to use log4j-to-jul with log4j-web
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
Re: Facing issue in while doing migration log4j 1.x to 2.x
Hi Nishu, On Tue, 16 May 2023 at 07:25, Nishu Gupta wrote: > Currently I am using log4j 1.x version. I am trying to migrate from 1.x to = > 2.x using bridge jar. > > we are using below category in log4j1.xml > eAppender"> > > (...) > > I am trying to convert into logj2.xml and we have custom class JMSQueueAppe= > nder which extends AppenderSkeleton for logging the event. Native Log4j 1.x appenders do work with Log4j 2.x if you: * use the `log4j-1.2-api` bridge, * use a Log4j 1.x configuration, * either set the system property `log4j.configuration` to the location of the above mentioned configuration or set `log4j1.compatibility` to `true`. These can constitute a fast **transitional** solution. You won't have access to all the configuration options of `log4j2.xml`, but you will not need to rewrite your appender. To fully migrate to Log4j 2.x you need: * either switch from your custom JMS appender to the one shipped with `log4j-core`: https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender * or rewrite your appender as a native Log4j 2.x Appender. Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: [ANNOUNCE] Apache Log4j Transformation Tools 0.1.0 released
Thanks Piotr! Gary On Sat, May 6, 2023, 15:16 Piotr P. Karwasz wrote: > The Apache Log4j 2 team is pleased to announce the Apache Log4j > Transformation Tools 0.1.0 release! > > Apache Log4j Transformation Tools is a subproject of Apache Log4j that > provides binary manipulation tools for Log4j-enabled software. > > In this first release you'll find: > > • A Maven plugin to precompute the location of your logging > statements. This allows you to include source location in your layout > configuration with virtually no performance penalty. > • The well known `maven-shaded-log4j-transformer` by Eduard > Gizatullin (https://github.com/edwgiz/maven-shaded-log4j-transformer), > that has been donated to the Apache Software Foundation by its author. > > You can find the project documentation at: > https://logging.apache.org/log4j/2.x/log4j-transform > > The binary artifacts are available in the Apache Maven repository: > > https://repository.apache.org/content/repositories/releases/ > > and also on Maven Central repository (https://repo1.maven.org/maven2/) > and its mirrors. > > The source distribution is available at: > https://dist.apache.org/repos/dist/release/logging/log4j-transform/0.1.0/ > > Bug reports, patches or suggestions for improvement can be submitted > through Github Issues: > https://github.com/apache/logging-log4j-transform/issues > > This release is dedicated to my wife Agnieszka for her birthday. > > Piotr Karwasz > > ----- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > >
[ANNOUNCE] Apache Log4j Transformation Tools 0.1.0 released
The Apache Log4j 2 team is pleased to announce the Apache Log4j Transformation Tools 0.1.0 release! Apache Log4j Transformation Tools is a subproject of Apache Log4j that provides binary manipulation tools for Log4j-enabled software. In this first release you'll find: • A Maven plugin to precompute the location of your logging statements. This allows you to include source location in your layout configuration with virtually no performance penalty. • The well known `maven-shaded-log4j-transformer` by Eduard Gizatullin (https://github.com/edwgiz/maven-shaded-log4j-transformer), that has been donated to the Apache Software Foundation by its author. You can find the project documentation at: https://logging.apache.org/log4j/2.x/log4j-transform The binary artifacts are available in the Apache Maven repository: https://repository.apache.org/content/repositories/releases/ and also on Maven Central repository (https://repo1.maven.org/maven2/) and its mirrors. The source distribution is available at: https://dist.apache.org/repos/dist/release/logging/log4j-transform/0.1.0/ Bug reports, patches or suggestions for improvement can be submitted through Github Issues: https://github.com/apache/logging-log4j-transform/issues This release is dedicated to my wife Agnieszka for her birthday. Piotr Karwasz - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Java 17 does not satisfy the Java 11 dependency for log4j 2.17.1
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
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 > >
Re: Java 17 does not satisfy the Java 11 dependency for log4j 2.17.1
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
Java 17 does not satisfy the Java 11 dependency for log4j 2.17.1
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
[ANNOUNCE] Apache Log4j 2.20.0 released
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: Issue after moving to log4j 2.19
Hi Ralph,
It's a tomcat related issue.
If I execute my application with the latest version of 8.5 series (8.5.83), it
does not work.
Exactly the same using tomcat 8.5.39 works perfectly.
Thanks,
Joan.
-Original Message-
From: Ralph Goers
Sent: Monday, October 17, 2022 5:28 PM
To: Log4J Users List
Subject: Re: Issue after moving to log4j 2.19
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/log
> 4j.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/log4
> j.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/a59fb664774c44535c10
>> 8
>> 17900a80ed5/raw/8bb6b6a963a607f0d99105248ce32a28ad39590a/gistfile1.tx
>> t
>>
>> In this case logs are not created.
>>
>>
>> 2. Using "this.systemLog =
>> LogManager.getContext().getLogger("LOGGER_SYSTEM");":
>> https://gist.githubusercontent.com/joanbalaguero/acd0a4edaf856ad34c44
>> a
>> 196caef7bdc/raw/474febc0397b97a9b941dbd86b830149ac94ad07/gistfile1.tx
>> t
>>
>> 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.AsyncLogge
>> r
>> ContextSelector
>>
>>
>> The point is that for years we have been running this without issues using
>> point 1, without getting the context from the L
Re: Issue after moving to log4j 2.19
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
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,
>
> 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#ContextSele
> ctor
>
> `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
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,
>
> 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#ContextSele
> ctor
>
> `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
-
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
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/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
-
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
Hi Joan,
On Sun, 16 Oct 2022 at 00:45, Joan ventusproxy
wrote:
> The " log4j.configurationFile " variable is set in this way:
> System.setProperty("log4j.configurationFile",
> "/opt/ventusproxy/app/proxy/ROOT/WEB-INF/log4j.xml");
For some unknown reason this is executed too late (after Log4j2
configuration). In the second file you posted you can see that Log4j2
is initialized twice: the first time the logger context associated
with your web app's classloader picks up the default configuration,
because no `log4j2.configurationFile` setting is visible. Then
`log4j-web` configures what seems to be a second logger context with
your configuration (but `log4j-web` uses the `ServletContext` init
params to retrieve the configuration).
To find which component calls Log4j2 before `log4j-web` you can use
`-Dlog4j2.loggerContextStacktraceOnStart=true`. The web fragment
`log4j` contained in `log4j-web` requests to be executed before all
others, but you can change it with `` in your
`web.xml`.
> And tomcat starts with:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
This setting basically breaks `log4j-web` ("WARN StatusLogger
Potential problem: Selector is not an instance of
NamedContextSelector."). Look into your web application descriptor and
remove the `isLog4jContextSelectorNamed` parameter. You can also use
the `BasicAsyncLoggerContextSelector` which always selects a thread
bound logger context (`log4j-web` manages the thread binding).
Piotr
-----
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: 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/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: Issue after moving to log4j 2.19
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
Re: JPMS Native Log4j?
> 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
Re: JPMS Native Log4j?
Hi Clayton, On Fri, 14 Oct 2022 at 17:32, Clayton Wohl wrote: > > I've heard rumors that the log4j devs are working on a Java 11+ JPMS native > version of log4j. This would help end users use jlink to package/distribute > their applications. Is this still happening? Is there a ballpark time > frame for when we will see pre-release builds? The upcoming 3.x series will fully support JPMS. See the `master` branch: https://github.com/apache/logging-log4j2/tree/master While it is now our main development effort and snapshots are published regularly (on https://repository.apache.org/content/groups/snapshots) after each commit, it is not very well tested by the community. JPMS-savy contributors are always welcome. Piotr - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
JPMS Native Log4j?
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?
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
Issue after moving to log4j 2.19
Hello,
�
We have moved to log4j 2.19.0 from log4j 2.17.2. Our environment is Centos9
stream with tomcat 8.5.83 and jdk11. After doing that, logging has stopped
working (the code related to log4j2 has not been changed for years)
�
All our loggers are asynchronous by adding:
-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
�
The piece of log4j.xml:
�
%d{-MM-dd HH:mm:ss}\t%m%n
�
�
�
Adding this before log creation:
System.setProperty("log4j2.debug", "true");
�
We only got this when we printed the variable that should contain the system
logger:
LOGGER_SYSTEM:ERROR in AsyncContext@587d32cc
�
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");
�
And now it is almost working again, because the hazelcast log is not sent to
the system logger yet. So our questions are:
�
1. Why must we get the logger from the context now? What has changed?
2. What should we do to get the hazelcast logging working again, so send
it to the system logger correctly.
�
�
Thanks,
�
Joan.
[ANNOUNCE] Apache Log4j 2.19.0 released
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: Converting custom Appender to Log4j v2
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
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
>
>
Re: Converting custom Appender to Log4j v2
> 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
I've found this code which also uses the missing FileAppender.setFile()
method:
```
public static void setFileAppenderOutput(String filename) {
File file = new File(filename);
FileAppender fa = null;
Enumeration e = Logger.getRootLogger().getAllAppenders();
while (e.hasMoreElements()) {
Appender a = (Appender) e.nextElement();
if ((FileAppender.class).isAssignableFrom(a.getClass())) {
fa = (FileAppender) a;
}
}
if (fa == null) {
fa = new FileAppender();
Layout l = new PatternLayout("%d{-MM-dd HH:mm:ss,SSSZ} %-5p
%c{1} %m%n");
fa.setLayout(l);
fa.setThreshold(Level.DEBUG);
Logger.getRootLogger().addAppender(fa);
}
fa.setFile(file.getAbsolutePath());
}
```
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.
Joel
On Wed, Aug 24, 2022 at 3:51 PM Ralph Goers
wrote:
> 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 <
> markus.dimmerl...@ppi.de>
> > 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
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
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">
> ...
>
>
>
>
>
RE: Converting custom Appender to Log4j v2
> 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. ...
Re: Converting custom Appender to Log4j v2
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
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 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
Re: Converting custom Appender to Log4j v2
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: Converting custom Appender to Log4j v2
Thanks for the code and information, even though it's a dispiriting
answer. If I have to write a new file, it'll likely take me most of a
year, if I'm even able to do it at all. It looks like the only feasible
way to remediate this code is either to remove logging altogether or maybe
see if running in bridge mode indefinitely will work.
Thanks again!
Joel
On Fri, Aug 12, 2022 at 8:01 PM Stephen Johns
wrote:
> Actually created new logger from scratch through code:
>
> Here is relevant code
>
> where pLogFilename is something like "MyServer.log"
>
>
>
> public static void initialize(String pLogFilename, String
> pConfigurationFilename) throws IOException {
> // Make sure the filename has the proper date format and is escaped
> to
> // allow passing through a SimpleDateFormat
> String _strPrefix = "";
> String _strSuffix = "";
> int i = pLogFilename.lastIndexOf('.');
> if (i >= 0) {
> _strPrefix = pLogFilename.substring(0, i);
> _strSuffix = pLogFilename.substring(i);
> } else {
> _strPrefix = pLogFilename;
> }
>
> pLogFilename = "'" + _strPrefix + "'MMdd";
> if (_strSuffix.length() > 0)
> pLogFilename += "'" + _strSuffix + "'";
>
> createLogger(pConfigurationFilename, _strPrefix, "MMdd",
> _strSuffix);
> }
>
>
> public static void createLogger(String pConfigFilename,
> String plogFilenamePrefix,
> String pLogFilenameDateFormat,
> String pLogFileNameSuffix) throws
> IOException {
> SimpleDateFormat _sdf = new
> SimpleDateFormat(pLogFilenameDateFormat);
> String _filename = plogFilenamePrefix + _sdf.format(new Date()) +
> pLogFileNameSuffix;
> createLogger(pConfigFilename, _filename,
> plogFilenamePrefix + "%d{" + pLogFilenameDateFormat + "}" +
> pLogFileNameSuffix);
> }
>
>
> /**
> * @param pConfigurationFilename
> * @param pLogFilename
> * @param pLogFilenamePattern
> * @throws IOException
> */
> public static void createLogger(String pConfigurationFilename,
> String pLogFilename,
> String pLogFilenamePattern) throws
> IOException {
>
> FileInputStream fileInputStream = new
> FileInputStream(pConfigurationFilename);
> ConfigurationSource configurationSource = new
> ConfigurationSource(fileInputStream);
>
> ConfigurationBuilder configurationBuilder =
> ConfigurationBuilderFactory.newConfigurationBuilder();
> configurationBuilder.setConfigurationSource(configurationSource);
>
> AppenderComponentBuilder log4jFileAppenderBuilder =
> configurationBuilder.
> newAppender("DailyRollingFileAppender", "RollingFile");
> log4jFileAppenderBuilder.addAttribute("filename", pLogFilename);
> log4jFileAppenderBuilder.addAttribute("filePattern",
> pLogFilenamePattern);
>
> // set up 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",
> "%d{ABSOLUTE} %-5p %m%n");
> log4jFileAppenderBuilder.add(layoutComponentBuilder);
>
> // Add it back into configuration
> configurationBuilder.add(log4jFileAppenderBuilder);
>
> // Set up root
> RootLoggerComponentBuilder rootLogger =
> configurationBuilder.newRootLogger().
>
> add(configurationBuilder.newAppenderRef("DailyRollingFileAppender"));
> configurationBuilder.add(rootLogger);
>
> // Actually use it
> Configurator.reconfigure(configurationBuilder.build());
> //System.out.println("\n***
> LOG CONFIG ****");
> // this is for debug - will print out what was created
> configurationBuilder.writeXmlConfiguration(System.out);
>
> }
>
>
> On Fri, Aug 12, 2022 at 6:18 PM Gary Gregory
> wrote:
>
Re: Converting custom Appender to Log4j v2
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 > > >
