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

[Piers Uso Walter]

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

[Piotr P. Karwasz]

Hi Piers,

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

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

Piotr

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

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

[Piotr P. Karwasz]

Hi Piers,

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

Sorry for the late answer.

There are two solutions I could think of:

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


log4jConfiguration

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


2. You could write container specific documentation:

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

Piotr

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

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

[Piers Uso Walter]

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

[Piers Uso Walter]

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

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

[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:




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

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

[Jeffrey.Thomas]

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

[Piers Uso Walter]

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

[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

[Piers Uso Walter]

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

[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

Re: Log4j module deprecation

[Piotr P. Karwasz]

Hi all,

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

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

Piotr

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

Re: Log4j module deprecation

[Christian Grobmeier]

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 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/_/b

Re: Log4j module deprecation

[Ralph Goers]

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


Ralph

> On Sep 29, 2023, at 5:36 AM, Christian Grobmeier  wrote:
> 
> From an observer of this discussion:
> 
> And I was thinking we have had this discussion over at dev@. I am surprised 
> we have seen something which I understood as agreement and then, when we tell 
> the users about our plans, we reopen this discussion.
> 
> This must be very frustrating for Piotr who collected all the feedback, 
> crafted that message and even shared it, and is now faced with the situation 
> when he tells a wider audience that we basically tell him to start over.
> 
> On the technical note, I feel we have too many modules only few people would 
> use. We should clean up and create a place for those modules.
> 
> Unfortunately I don’t know these modules so I can’t tell, but the way we had 
> this discussion is extremely frustrating. We should continue on dev@ (again)
> 
> On Thu, Sep 28, 2023, at 22:15, Ralph Goers wrote:
>> I created the docker and Kubernetes modules. Originally my employer 
>> used them when sending data directly via TCP to a forwarder. However, 
>> we ran into reliability issues with the forwarder when doing that so we 
>> switched to writing to the console, despite benchmarks showing it is 
>> slower. But for anyone implementing something that avoids those issues 
>> this would be very relevant.  By archiving this we are basically 
>> telling users that they cannot use it any more since it will no longer 
>> be supported. For that reason I am not in favor of that for these two 
>> components.
>> 
>> Ralph
>> 
>>> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> We always strive to only release industrial-strength components.
>>> 
>>> Following an internal discussion and looking at statistics from
>>> several sources, the PMC plans to deprecate in the 2.x version several
>>> components for removal in 3.x.
>>> 
>>> We know that statistics are not everything and that is why we would
>>> like to hear your opinion on these modules. The discussion will be
>>> open for a month, after which the PMC will announce a definitive list
>>> of deprecations.
>>> 
>>> ## `log4j-cassandra`:
>>>   We support Cassandra 3.x. This release will reach end-of-life when
>>> 4.2.x is released[1]. Since the stats show marginal usage of the
>>> module, there should be no `log4j-cassandra4`.
>>> 
>>> ## CouchDB appender:
>>>  It is even less used than Cassandra according to the stats.
>>> 
>>> ## `log4j-docker`
>>>   Seldom used and standard practice is generally to log to the
>>> console and let the Docker environment add the data.
>>> 
>>> ## GELF appender:
>>>   It is mostly superseded by `JsonTemplateLayout`.
>>> 
>>> ## Kafka appender:
>>>   It contains several critical bug reports neither the PMC, nor the
>>> community is willing to deal with.
>>> 
>>> ## `log4j-kubernetes`:
>>>   Seldom used and standard practice is generally to log to the
>>> console and let the Docker environment add the data.
>>> 
>>> ## JeroMQ appender:
>>>   Since version 2.6 it had only one PR/bug report and it was from
>>> PAX Logging maintainer. There is an alternative from a ZeroMQ
>>> maintainer[2], Fabrice Bacchella, that provides important features
>>> like encryption or choice of socket type.
>>> 
>>> ## JNDI-related features:
>>>   JNDI is an old technology from the times of ponies and unicorns,
>>> when nobody cared about security. The Error Prone team decided to mark
>>> JNDI usage as error by default[3].
>>> 
>>> ## `log4j-jpa`:
>>>   Has marginal downloads and requires a migration to Jakarta EE. I
>>> think that `log4j-jdbc` (which is also seldom used) provides a good
>>> alternative for SQL databases,
>>> 
>>> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>>>   We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
>>> used and `YamlLayout` as far as we know is not be used at all.
>>> 
>>> ## `log4j-mongodb3`:
>>>   Support for MongoDB 3.x ended two years ago.
>>> 
>>> ## `log4j-spring-boot`:
>>>   Its features are included in 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 unsubs

Re: Log4j module deprecation

[Christian Grobmeier]

>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

[Ralph Goers]

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

Ralph

> On Sep 28, 2023, at 12:35 AM, Piotr P. Karwasz  
> wrote:
> 
> Hi all,
> 
> We always strive to only release industrial-strength components.
> 
> Following an internal discussion and looking at statistics from
> several sources, the PMC plans to deprecate in the 2.x version several
> components for removal in 3.x.
> 
> We know that statistics are not everything and that is why we would
> like to hear your opinion on these modules. The discussion will be
> open for a month, after which the PMC will announce a definitive list
> of deprecations.
> 
> ## `log4j-cassandra`:
>We support Cassandra 3.x. This release will reach end-of-life when
> 4.2.x is released[1]. Since the stats show marginal usage of the
> module, there should be no `log4j-cassandra4`.
> 
> ## CouchDB appender:
>   It is even less used than Cassandra according to the stats.
> 
> ## `log4j-docker`
>Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
> 
> ## GELF appender:
>It is mostly superseded by `JsonTemplateLayout`.
> 
> ## Kafka appender:
>It contains several critical bug reports neither the PMC, nor the
> community is willing to deal with.
> 
> ## `log4j-kubernetes`:
>Seldom used and standard practice is generally to log to the
> console and let the Docker environment add the data.
> 
> ## JeroMQ appender:
>Since version 2.6 it had only one PR/bug report and it was from
> PAX Logging maintainer. There is an alternative from a ZeroMQ
> maintainer[2], Fabrice Bacchella, that provides important features
> like encryption or choice of socket type.
> 
> ## JNDI-related features:
>JNDI is an old technology from the times of ponies and unicorns,
> when nobody cared about security. The Error Prone team decided to mark
> JNDI usage as error by default[3].
> 
> ## `log4j-jpa`:
>Has marginal downloads and requires a migration to Jakarta EE. I
> think that `log4j-jdbc` (which is also seldom used) provides a good
> alternative for SQL databases,
> 
> ## Jackson based layouts (JsonLayout, XmlLayout, YamlLayout)
>We already provide `JsonTemplateLayout`; `XmlLayout` is seldom
> used and `YamlLayout` as far as we know is not be used at all.
> 
> ## `log4j-mongodb3`:
>Support for MongoDB 3.x ended two years ago.
> 
> ## `log4j-spring-boot`:
>Its features are included in Spring Boot 3.x.
> 
> ## SMTP appender:
>Its usage is at the bottom of the stats.
> 
> ## `log4j-taglib`
>Also needs a Jakarta version, but it is based on a legacy
> technology that is currently seldom used.
> 
> Waiting to hear your opinions,
> Piotr
> 
> [1] 
> https://cassandra.apache.org/_/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.html
> [2] https://github.com/fbacchella/loghublog4j2
> [3] https://errorprone.info/bugpattern/BanJNDI
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 


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

Re: Log4j module deprecation

[Matt Sicker]

* 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

[Volkan Yazıcı]

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

[Wayne Cannon]

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

[Volkan Yazıcı]

I have cross-posted this to GitHub Discussions
 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 1.2.x Customer Appender not used as "Plugin" by Log4j 1.2 Bridge

[Pablo Rogina]

Hi Piotr,

your suggestion did the trick.

I added a CustomAppenderBuilder into the same package of my
CustomAppender based on Log4j2.
So this new CustomAppenderBuilder can parse a Properties object in
Log4j1 syntax and creates CustomAppender v2 via AppenderWrapper (from
the Log4j 1.2 Bridge).

In summary, no changes to the application: it continues using loggers
from v1, keeps using a Properties object with Log4j1 syntax for
configuration, while the actual management of log files is carried on
by Log4j2-based CustomAppender.

Thank you for the assistance!

Regards. Pablo

On Wed, Mar 30, 2022 at 5:44 AM Piotr P. Karwasz
 wrote:
>
> Hello Pablo,
>
> On Tue, 29 Mar 2022 at 19:58, Pablo Rogina  wrote:
> > However this warning appears (application launched with 
> > -Dlog4j2.debug=true):
> > WARN StatusLogger Unable to load plugin class name
> > com.mycompany.log4j.CustomAppender with key
> > com.mycompany.log4j.customappender
>
> This is an expected behavior. Most common Log4j 1.x components are
> actually translated into their Log4j 2.x equivalents using
> configuration builder plugins. See [1] for example. If you were using
> "standard" Log4j 1.x components (e.g. org.apache.log4j.FileAppender),
> this warning means that the system is using the real
> org.apache.log4jFileAppender class instead of its Log4j 2.x
> equivalent, which might result in poor performance.
>
> You can actually also write such a builder plugin yourself, if you
> wish to use a Log4j 1.x configuration to start your custom Log4j 2.x
> appender.
>
> Piotr
>
> [1] 
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-1.2-api/src/main/java/org/apache/log4j/builders/appender/RollingFileAppenderBuilder.java
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>

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

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

[Piotr P. Karwasz]

Hello Pablo,

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

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

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

Piotr

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

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

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

[Ralph Goers]

Comments below.

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


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

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

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

Ralph

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

[Pablo Rogina]

Ralph, thank you for your reply.

> To be usable in your configuration a Log4j 1.2 Appender cannot be a Log4j2 
> plugin.
Ok. It is not, as my CustomAppender extends RollingFileAppender (from
Log4j v 1.2.x)

> You would configure it exactly as you do in log4j 1.x, via its class name.
Ok. I think it's what I'm doing.
This is the properties I'm using to configure my app logging:
log4j.appender.MYAPPLOGFILE=com.mycompany.log4j.CustomAppender
log4j.appender.MYAPPLOGFILE.Append=false
log4j.appender.MYAPPLOGFILE.SpecialValue=ABC
log4j.appender.MYAPPLOGFILE.HeaderVersion=1
log4j.appender.MYAPPLOGFILE.File=logs/MyApp.log
log4j.appender.MYAPPLOGFILE.MaxBackupIndex=19
log4j.appender.MYAPPLOGFILE.MaxFileSize=2000KB
log4j.appender.MYAPPLOGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.MYAPPLOGFILE.layout.ConversionPattern=%d{[dd MMM 
HH\:mm\:ss,SSS]}[%t]\:%-5p\:%l -->%m%n
log4j.rootLogger=INFO, MYAPPLOGFILE

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

Well, I also have a CustomAppender for Log4j 2 that resembles a
RollingFileAppender, defined like this:

@Plugin(name = CustomAppender.PLUGIN_NAME, category =
Core.CATEGORY_NAME, elementType = Appender.ELEMENT_TYPE, printObject =
true)
public final class CustomAppender extends
AbstractOutputStreamAppender {
...

however I also got the "Unable to load plugin class name ..." issue if
using the CustomAppender v2.
And I also find difficult to configure it via Properties using the
Log4j 1.2 Bridge

Regards. Pablo

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

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

[Ralph Goers]

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

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

Ralph

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


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

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

[Ralph Goers]

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

Ralph

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


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

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

[Janaka Bandara]

Thanks @Volkan! I'll raise a JIRA ticket.

Also thanks @Damien for the pointer on %xEx (before starting this
thread I did look up the mail archives but could not find your thread
- possibly my inexperience with the filtering).

Given that the feature is already supported in
ExtendedThrowablePatternConverter, I believe the proper "fix" here
would be to update the documentation to point to %xEx for
{filters(..)} syntax/usage (since filtering stack frames is actually
not a common requirement, bringing the feature into %ex might be an
unnecessary overhead after all). WDYT?

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


-- 
Janaka Bandara

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

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

[Volkan Yazıcı]

Hello Janaka & Damien,

This discrepancy indeed seems like a bug. Would you mind first filing a
JIRA ticket, please?

@Janaka, if you can contribute this feature in a PR that would be great! To
avoid redundant iterations, would you mind briefly describing how you plan
to address the issue in the ticket before starting to implement anything,
please?

Cheers!

On Mon, Feb 14, 2022 at 11:00 PM Damien Jiang 
wrote:

> I also sent a message to the mailing list about this 4 days before:
> https://lists.apache.org/thread/yoj9bdfqfph6q03t26r5mrdc37zjd9nw
> but there's been no response yet.
>
> For now I just started using %xEx, but I'd appreciate it if this feature
> could be supported for %ex as well.
>
> Thanks,
> Damien
>
> On Sun, Feb 13, 2022 at 6:40 PM Janaka Bandara 
> wrote:
>
> > Hello everyone,
> >
> > PatternLayout (
> > https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout)
> > advertises this parameter syntax, to allow filtering undesired stack
> > frames from logged stacktraces: `%ex{filters(package,list)}`
> >
> > > ex|exception|throwable
> > >
> > > {filters(package,package,...)}
> > >
> > > Use {filters(packages)} where packages is a list of package names to
> > suppress matching stack frames from stack traces.
> >
> >
> > However on 2.17.1 (latest) when I use such a pattern:
> >
> > ``
> >
> > no filtering happens, and I still get stacktraces like:
> >
> > ```
> > 2022-02-14T07:25:23,048 ERROR TestLog error
> > java.lang.IllegalStateException: Oh no
> > at org.p2.Foo.run(Foo.java:5)
> > at com.p1.Bar.run(Bar.java:7)
> > at org.p2.Bar.run(Bar.java:5)
> > at com.p1.Foo.run(Foo.java:7)
> > at TestLog.main(TestLog.java:11)
> > ```
> >
> >
> > Per my understanding, above config should remove the two `at
> > org.p2...` frames/lines from the stacktrace.
> >
> > Turning off `alwaysWriteExceptions` makes no change.
> >
> >
> > Looking at the
> >
> `org.apache.logging.log4j.core.impl.ThrowableFormatOptions#newInstance(..)`
> > codebase I see that the `filters` parameter is parsed and loaded to
> > `ThrowableFormatOptions` properly; but in the actual
> >
> >
> `org.apache.logging.log4j.core.pattern.ThrowablePatternConverter#formatOption(..)`
> > I cannot find any stack frame filtering logic using `filters` config.
> > So to me it seems like `filters` functionality is not yet implemented
> > (although I could not find any documentation/discussions to back my
> > suspicion).
> >
> >
> > I would be happy to contribute a filtering implementation honoring the
> > already documented specification; however first I would like to
> > confirm if I'm correct so far, or if I have missed something.
> >
> > TIA!
> >
> > --
> > Janaka Bandara
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>

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

[Damien Jiang]

I also sent a message to the mailing list about this 4 days before:
https://lists.apache.org/thread/yoj9bdfqfph6q03t26r5mrdc37zjd9nw
but there's been no response yet.

For now I just started using %xEx, but I'd appreciate it if this feature
could be supported for %ex as well.

Thanks,
Damien

On Sun, Feb 13, 2022 at 6:40 PM Janaka Bandara 
wrote:

> Hello everyone,
>
> PatternLayout (
> https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout)
> advertises this parameter syntax, to allow filtering undesired stack
> frames from logged stacktraces: `%ex{filters(package,list)}`
>
> > ex|exception|throwable
> >
> > {filters(package,package,...)}
> >
> > Use {filters(packages)} where packages is a list of package names to
> suppress matching stack frames from stack traces.
>
>
> However on 2.17.1 (latest) when I use such a pattern:
>
> ``
>
> no filtering happens, and I still get stacktraces like:
>
> ```
> 2022-02-14T07:25:23,048 ERROR TestLog error
> java.lang.IllegalStateException: Oh no
> at org.p2.Foo.run(Foo.java:5)
> at com.p1.Bar.run(Bar.java:7)
> at org.p2.Bar.run(Bar.java:5)
> at com.p1.Foo.run(Foo.java:7)
> at TestLog.main(TestLog.java:11)
> ```
>
>
> Per my understanding, above config should remove the two `at
> org.p2...` frames/lines from the stacktrace.
>
> Turning off `alwaysWriteExceptions` makes no change.
>
>
> Looking at the
> `org.apache.logging.log4j.core.impl.ThrowableFormatOptions#newInstance(..)`
> codebase I see that the `filters` parameter is parsed and loaded to
> `ThrowableFormatOptions` properly; but in the actual
>
> `org.apache.logging.log4j.core.pattern.ThrowablePatternConverter#formatOption(..)`
> I cannot find any stack frame filtering logic using `filters` config.
> So to me it seems like `filters` functionality is not yet implemented
> (although I could not find any documentation/discussions to back my
> suspicion).
>
>
> I would be happy to contribute a filtering implementation honoring the
> already documented specification; however first I would like to
> confirm if I'm correct so far, or if I have missed something.
>
> TIA!
>
> --
> Janaka Bandara
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Log4j

[Volkan Yazıcı]

Hello Thyagarajan,

`secur...@logging.apache.org` list is used for vulnerability reports, not
user questions. Please use `log4j-user@logging.apache.org` mailing list for
your questions.

Below I try to answer your questions:

> 1) Is there any script or command to verify which application utilizes
log4j version

No, there is no such one-size-fits-all script or command.

> 2) do we have any steps how to upgrade Log4j version from lesser version
to fix version
> Old version: 2.16.0 -> Upgrade to 2.17.1
> Old version less than 2.12.4 -> Upgrade to 2.12.4
> Old version less than 2.3.2 -> Upgrade to 2.3.2

I think there is a slight mistake in your reasoning. Every Log4j 2 user is
recommended to upgrade to the latest version, that is, 2.17.1, which
requires Java 8. For those who cannot upgrade to 2.17.1 due to Java
compatibility reasons, they are recommended to upgrade to 2.12.4 for Java 7
and 2.3.2 for Java 6.

On how to upgrade... In most cases, replacing the old log4j-core-2.X.X.jar
in your classpath with log4j-core-2.17.1 should simply work. If this
doesn't work for you, you can again consult this mailing list.

Kind regards.


On Fri, Feb 4, 2022 at 4:07 AM Krishnaswami, Thyagarajan <
t.krishnasw...@dxc.com> wrote:

> Hi Security team,
>
> I’m from SCCM support team. We do all applications deploy via sccm to
> workstation.
>
> We have many applications support of Log4j.
>
> Currently , we are identifying the applications which support Log4j and
> doing uninstall of that application.
>
>
>
> I saw the link . The following log4j has fix.
>
> https://logging.apache.org/log4j/2.x/security.html
> 
>
>
>
>
>
> I need few information.
>
>
>
> 1)Is there any script or command to verify which application utilizes
> log4j version
>
> 2) do we have any steps how to upgrade Log4j version from lesser version
> to fix version
>
> Old version: 2.16.0 -> Upgrade to 2.17.1
>
> Old version less than 2.12.4 -> Upgrade to 2.12.4
>
> Old version less than 2.3.2 -> Upgrade to 2.3.2
>
>
>
> Thanks &Regards,
>
> Thyagarajan
>
> M +91 9884337499
> *DXC Technology*
> Chennai-600113
>
>
> dxc.technology 
>
>
>
>
> DXC Technology Company -- This message is transmitted to you by or on
> behalf of DXC Technology Company or one of its affiliates. It is intended
> exclusively for the addressee. The substance of this message, along with
> any attachments, may contain proprietary, confidential or privileged
> information or information that is otherwise legally exempt from
> disclosure. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient of this message, you are
> not authorized to read, print, retain, copy or disseminate any part of this
> message. If you have received this message in error, please destroy and
> delete all copies and notify the sender by return e-mail. Regardless of
> content, this e-mail shall not operate to bind DXC Technology Company or
> any of its affiliates to any order or other contract unless pursuant to
> explicit written agreement or government initiative expressly permitting
> the use of e-mail for such purpose.
>

Re: log4j RollingFileAppender filePattern issue when using the log4j Bridge

[Ralph Goers]

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

Ralph

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


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

Re: log4j use bridge

[Volkan Yazıcı]

Hello,

Please use log4j-user@logging.apache.org mailing list for questions, so
that others can benefit too. security@ mailing list is used for reporting
vulnerabilities.

Log4j1 and Log4j2 are two totally separate code bases. The vulnerabilities
affecting them are different too, hence those are assigned to different
CVEs. If I understand correctly, initially, your application had a
`log4j.xml` (Log4j1 configuration) and `log4j-1.2.17.jar` (Log4j1 itself).
Log4j1 reached its end-of-life in 2015 and has not been maintained since
then, putting aside both known and unknown vulnerabilities associated with
it. Hence we strongly recommend you to move away from Log4j1. As you have
also noted, you can upgrade to Log4j2 in various ways
, of which
using the `log4j-1.2-api` bridge is one of them. In this method, you will
end up having a Log4j1 configuration (`log4j.xml`), `log4j-1.2-api` and
`log4j-core` JARs. Since these two JARs are part of Log4j2, now you are
subject to Log4j2 vulnerabilities. Put another way, your project doesn't
depend on Log4j1 anymore and hence, is not prone to Log4j1 vulnerabilities.
That is why, once you employ `log4j-1.2-api` and `log4j-core`, you should
upgrade both JARs to the most recent Log4j2 version.

Kind regards.

On Tue, Jan 4, 2022 at 7:12 AM 이초  wrote:

> Hello.
> Please forgive me for using a translator.
>
> I am using Log4j version 1.x and upgrading to Log4j version 2 is in
> progress.
> There is a way to remove the class file, but internally, upgrading is
> recommended. It was a difficult situation to upgrade because it was a
> legacy system, but it was confirmed that it works normally with the
> log4j-1.2-api bridge function. The problem is that the official document or
> the document of public institutions says to upgrade, and there is no
> information about whether it can be handled with the bridge function.
> It is said that only the official content is recognized internally, but I
> wonder if the current security issue and the problem of the previous 1.x
> version will be resolved if the bridge method is used to handle the latest
> version 2.17.
> And is it possible to announce this content on the apache logging site,
> even briefly?
> I know you are busy, but please check it. happy New Year. thank you.
>

Re: Log4j issue

[bab]

I cannot understand what does this mean

Otherwise, in the configuration, remove references to Context Lookups  
like ${ctx:loginId} or $${ctx:loginId} where they originate from  
sources external to the application such as HTTP headers or user input.


1- Would you say what should I do exactly ?
2- Would you say what string should I looking for in Log4j-config.xsd ?
3- Do I have to looking for in Log4j-config.xsd ?
4- Would you say exactly what parameters should remove ?

BR



Quoting b...@virtualcdc.com:


Is that your means have to search  "${ctx" in Log4j-config.xsd file ?
Would you say exactly what parameters need to remove from  
Log4j-config.xsd file?



Quoting Tushar Kapila :


Exact plain string (Non regex) to search would be
"${ctx"

"somekey" is a placeholder for name of variable.

On Mon, 20 Dec, 2021, 16:29 ,  wrote:


I searched ${ctx:somekey} in the log4j-config.xsd file but could not
find anything .
Is that means that is enough If we upgrade to 2.17 or just remove the
class file?


Quoting Ralph Goers :


Removing JndiLookup helps by preventing the JNDI attack. You
absolutely need to do this if you do not upgrade.

For item 2 look at your log4j2 configuration file. If it contains
${ctx:somekey} then you need to understand how somekey is being
populated. I would venture to guess that most Log4j2 configurations
won’t have ${ctx: in them in which case there is nothing to do.

Ralph


On Dec 19, 2021, at 9:54 PM, b...@virtualcdc.com wrote:


Dear team
Hi.

According to Log4j vulnerability as I know one of the solution was
remove JndiLookup.class file from log4j-core-*.jar file .

But now we see other vulnerability :

upgrade to 2.17 or
Otherwise, in the configuration, remove references to Context
Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate
from sources external to the application such as HTTP headers or
user input.

1- Is that your mean remove class file (JndiLookup.class) cannot help

us ?

2- Would you please say how we can do this on Linux systems ?
in the configuration, remove references to Context Lookups like
${ctx:loginId} or $${ctx:loginId} where they originate from sources
external to the application such as HTTP headers or user input.

Best regards.


-
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





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

Re: Log4j issue

[bab]

Is that your means have to search  "${ctx" in Log4j-config.xsd file ?
Would you say exactly what parameters need to remove from  
Log4j-config.xsd file?



Quoting Tushar Kapila :


Exact plain string (Non regex) to search would be
"${ctx"

"somekey" is a placeholder for name of variable.

On Mon, 20 Dec, 2021, 16:29 ,  wrote:


I searched ${ctx:somekey} in the log4j-config.xsd file but could not
find anything .
Is that means that is enough If we upgrade to 2.17 or just remove the
class file?


Quoting Ralph Goers :

> Removing JndiLookup helps by preventing the JNDI attack. You
> absolutely need to do this if you do not upgrade.
>
> For item 2 look at your log4j2 configuration file. If it contains
> ${ctx:somekey} then you need to understand how somekey is being
> populated. I would venture to guess that most Log4j2 configurations
> won’t have ${ctx: in them in which case there is nothing to do.
>
> Ralph
>
>> On Dec 19, 2021, at 9:54 PM, b...@virtualcdc.com wrote:
>>
>>
>> Dear team
>> Hi.
>>
>> According to Log4j vulnerability as I know one of the solution was
>> remove JndiLookup.class file from log4j-core-*.jar file .
>>
>> But now we see other vulnerability :
>>
>> upgrade to 2.17 or
>> Otherwise, in the configuration, remove references to Context
>> Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate
>> from sources external to the application such as HTTP headers or
>> user input.
>>
>> 1- Is that your mean remove class file (JndiLookup.class) cannot help
us ?
>> 2- Would you please say how we can do this on Linux systems ?
>> in the configuration, remove references to Context Lookups like
>> ${ctx:loginId} or $${ctx:loginId} where they originate from sources
>> external to the application such as HTTP headers or user input.
>>
>> Best regards.
>>
>>
>> -
>> 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: Log4j issue

[Tushar Kapila]

Exact plain string (Non regex) to search would be
"${ctx"

"somekey" is a placeholder for name of variable.

On Mon, 20 Dec, 2021, 16:29 ,  wrote:

> I searched ${ctx:somekey} in the log4j-config.xsd file but could not
> find anything .
> Is that means that is enough If we upgrade to 2.17 or just remove the
> class file?
>
>
> Quoting Ralph Goers :
>
> > Removing JndiLookup helps by preventing the JNDI attack. You
> > absolutely need to do this if you do not upgrade.
> >
> > For item 2 look at your log4j2 configuration file. If it contains
> > ${ctx:somekey} then you need to understand how somekey is being
> > populated. I would venture to guess that most Log4j2 configurations
> > won’t have ${ctx: in them in which case there is nothing to do.
> >
> > Ralph
> >
> >> On Dec 19, 2021, at 9:54 PM, b...@virtualcdc.com wrote:
> >>
> >>
> >> Dear team
> >> Hi.
> >>
> >> According to Log4j vulnerability as I know one of the solution was
> >> remove JndiLookup.class file from log4j-core-*.jar file .
> >>
> >> But now we see other vulnerability :
> >>
> >> upgrade to 2.17 or
> >> Otherwise, in the configuration, remove references to Context
> >> Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate
> >> from sources external to the application such as HTTP headers or
> >> user input.
> >>
> >> 1- Is that your mean remove class file (JndiLookup.class) cannot help
> us ?
> >> 2- Would you please say how we can do this on Linux systems ?
> >> in the configuration, remove references to Context Lookups like
> >> ${ctx:loginId} or $${ctx:loginId} where they originate from sources
> >> external to the application such as HTTP headers or user input.
> >>
> >> Best regards.
> >>
> >>
> >> -
> >> 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 issue

[bab]

I searched ${ctx:somekey} in the log4j-config.xsd file but could not  
find anything .
Is that means that is enough If we upgrade to 2.17 or just remove the  
class file?



Quoting Ralph Goers :

Removing JndiLookup helps by preventing the JNDI attack. You  
absolutely need to do this if you do not upgrade.


For item 2 look at your log4j2 configuration file. If it contains  
${ctx:somekey} then you need to understand how somekey is being  
populated. I would venture to guess that most Log4j2 configurations  
won’t have ${ctx: in them in which case there is nothing to do.


Ralph


On Dec 19, 2021, at 9:54 PM, b...@virtualcdc.com wrote:


Dear team
Hi.

According to Log4j vulnerability as I know one of the solution was  
remove JndiLookup.class file from log4j-core-*.jar file .


But now we see other vulnerability :

upgrade to 2.17 or
Otherwise, in the configuration, remove references to Context  
Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate  
from sources external to the application such as HTTP headers or  
user input.


1- Is that your mean remove class file (JndiLookup.class) cannot help us ?
2- Would you please say how we can do this on Linux systems ?
in the configuration, remove references to Context Lookups like  
${ctx:loginId} or $${ctx:loginId} where they originate from sources  
external to the application such as HTTP headers or user input.


Best regards.


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

[bab]

I searched ${ctx:somekey} in the log4j-config.xsd file but could not  
find anything .
Is that means that is enough If we upgrade to 2.17 or just remove the  
class file?




Quoting Ralph Goers :

Removing JndiLookup helps by preventing the JNDI attack. You  
absolutely need to do this if you do not upgrade.


For item 2 look at your log4j2 configuration file. If it contains  
${ctx:somekey} then you need to understand how somekey is being  
populated. I would venture to guess that most Log4j2 configurations  
won’t have ${ctx: in them in which case there is nothing to do.


Ralph


On Dec 19, 2021, at 9:54 PM, b...@virtualcdc.com wrote:


Dear team
Hi.

According to Log4j vulnerability as I know one of the solution was  
remove JndiLookup.class file from log4j-core-*.jar file .


But now we see other vulnerability :

upgrade to 2.17 or
Otherwise, in the configuration, remove references to Context  
Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate  
from sources external to the application such as HTTP headers or  
user input.


1- Is that your mean remove class file (JndiLookup.class) cannot help us ?
2- Would you please say how we can do this on Linux systems ?
in the configuration, remove references to Context Lookups like  
${ctx:loginId} or $${ctx:loginId} where they originate from sources  
external to the application such as HTTP headers or user input.


Best regards.


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

[Ralph Goers]

Removing JndiLookup helps by preventing the JNDI attack. You absolutely need to 
do this if you do not upgrade.

For item 2 look at your log4j2 configuration file. If it contains 
${ctx:somekey} then you need to understand how somekey is being populated. I 
would venture to guess that most Log4j2 configurations won’t have ${ctx: in 
them in which case there is nothing to do.

Ralph

> On Dec 19, 2021, at 9:54 PM, b...@virtualcdc.com wrote:
> 
> 
> Dear team
> Hi.
> 
> According to Log4j vulnerability as I know one of the solution was remove 
> JndiLookup.class file from log4j-core-*.jar file .
> 
> But now we see other vulnerability :
> 
> upgrade to 2.17 or
> Otherwise, in the configuration, remove references to Context Lookups like 
> ${ctx:loginId} or $${ctx:loginId} where they originate from sources external 
> to the application such as HTTP headers or user input.
> 
> 1- Is that your mean remove class file (JndiLookup.class) cannot help us ?
> 2- Would you please say how we can do this on Linux systems ?
> in the configuration, remove references to Context Lookups like 
> ${ctx:loginId} or $${ctx:loginId} where they originate from sources external 
> to the application such as HTTP headers or user input.
> 
> Best regards.
> 
> 
> -
> 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 2.15.0 signature and sha512 hash

[Matt Sicker]

Thanks for confirming!
--
Matt Sicker

> On Dec 13, 2021, at 20:02, Daniel Savard  wrote:
> 
> Le lun. 13 déc. 2021 à 13:35, Daniel Savard  a
> écrit :
> 
>> 
>> -
>> Daniel Savard
>> 
>> 
>> Le lun. 13 déc. 2021 à 13:28, Gary Gregory  a
>> écrit :
>> 
>>> On Mon, Dec 13, 2021 at 1:22 PM Daniel Savard 
>>> wrote:
>>> 
 Le lun. 13 déc. 2021 à 12:34, Gary Gregory  a
 écrit :
 
> Works for me:
> 
> gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
> 
 
 Here is the content of the asc file:
 
 -BEGIN PGP SIGNATURE-
 
 iQIzBAABCgAdFiEEU8k1ghqmp1W9M321NZU5XrPY4boFAmGySd0ACgkQNZU5XrPY
 4bqQtQ/+KXQi3+6LZ13HyEefNsnBm84krCXK/nAIlRnerbV+Wj1g0xU7cC8l3m+n
 UHw2/BIIurGnOKU4bvGUOc5UYDTED4LPadkvXYW0NMvBGla0fvR1lyEMypS2E2nz
 0g3sqHC0T4ZEGEIO7jmUVQJEpPya33VlztfnoNQPcqv6PCOilIVK1EmoewEBvnsd
 SVAJPhJtD43mUPLsIMIc4k7IM56FssN+2+46mba6YH39C4Z4NheGBUK9UXWYKQd3
 3DKHoIoLb2hKXLdxHHz5u4dbkYPiHyGR4iX0wjq7W4eUX/4v+czsjrs8vQ5Gvhba
 slg6RfUeu+fkMJfQUgRLT2HRSIKsuUd2QMppxW1GKRnfpx0yzAUWMfFfPcxuEa/u
 em4YCsz1/a0AtfgtI6+Lne0yWsxORVVutquVOyF0ddjySQccPNYaOyOjx6jASM2A
 LxkdCko0+2rSuIWcLMpWaoeRedao4L6O3azdU0IcN7/BVyXczM2t5cYB4QDdXvSc
 UKJ6q6dQLngIwYqo6Q/d1XeKatWuhSPz0+mAoGAWvllvzWKb1/YbC/jZk/vxVqzR
 K/mHB24pPWfcWiQNfbHrOVVUzv783u1RkEqDCGbBNBUr+ud1Fvte0i1x6WIhGXS7
 qb5OTuljDicQ1L2mAKgvzl4XnOUsFmuBagZHYk58n19ZlxfBlyw=
 =gA3i
 
 -END PGP SIGNATURE-
 
 This results in a bad signature.
 
>>> 
>>> What happens when you run:
>>> 
>>> gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
>>> 
>>> ?
>>> 
>> 
>> $ gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
>> gpg: keyserver option 'honor-http-proxy' is unknown
>> gpg: les données signées sont supposées être dans «
>> apache-log4j-2.15.0-bin.tar.gz »
>> gpg: Signature faite le jeu 09 déc 2021 13:24:29 EST
>> gpg:avec la clef RSA
>> 53C935821AA6A755BD337DB53595395EB3D8E1BA
>> gpg: MAUVAISE signature de « Ralph Goers (CODE SIGNING KEY) <
>> rgo...@apache.org> » [inconnu]
>> 
>> MAUVAISE=BAD
>> 
>> 
>>> Gary
>>> 
>> 
>> 
> apache-log4j-2.16.0 is out and this time signature and hash validation work
> perfectly.
> 
> -
> Daniel Savard


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

Re: log4j 2.15.0 signature and sha512 hash

[Daniel Savard]

Le lun. 13 déc. 2021 à 13:35, Daniel Savard  a
écrit :

>
> -
> Daniel Savard
>
>
> Le lun. 13 déc. 2021 à 13:28, Gary Gregory  a
> écrit :
>
>> On Mon, Dec 13, 2021 at 1:22 PM Daniel Savard 
>> wrote:
>>
>> > Le lun. 13 déc. 2021 à 12:34, Gary Gregory  a
>> > écrit :
>> >
>> > > Works for me:
>> > >
>> > > gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
>> > >
>> >
>> > Here is the content of the asc file:
>> >
>> > -BEGIN PGP SIGNATURE-
>> >
>> > iQIzBAABCgAdFiEEU8k1ghqmp1W9M321NZU5XrPY4boFAmGySd0ACgkQNZU5XrPY
>> > 4bqQtQ/+KXQi3+6LZ13HyEefNsnBm84krCXK/nAIlRnerbV+Wj1g0xU7cC8l3m+n
>> > UHw2/BIIurGnOKU4bvGUOc5UYDTED4LPadkvXYW0NMvBGla0fvR1lyEMypS2E2nz
>> > 0g3sqHC0T4ZEGEIO7jmUVQJEpPya33VlztfnoNQPcqv6PCOilIVK1EmoewEBvnsd
>> > SVAJPhJtD43mUPLsIMIc4k7IM56FssN+2+46mba6YH39C4Z4NheGBUK9UXWYKQd3
>> > 3DKHoIoLb2hKXLdxHHz5u4dbkYPiHyGR4iX0wjq7W4eUX/4v+czsjrs8vQ5Gvhba
>> > slg6RfUeu+fkMJfQUgRLT2HRSIKsuUd2QMppxW1GKRnfpx0yzAUWMfFfPcxuEa/u
>> > em4YCsz1/a0AtfgtI6+Lne0yWsxORVVutquVOyF0ddjySQccPNYaOyOjx6jASM2A
>> > LxkdCko0+2rSuIWcLMpWaoeRedao4L6O3azdU0IcN7/BVyXczM2t5cYB4QDdXvSc
>> > UKJ6q6dQLngIwYqo6Q/d1XeKatWuhSPz0+mAoGAWvllvzWKb1/YbC/jZk/vxVqzR
>> > K/mHB24pPWfcWiQNfbHrOVVUzv783u1RkEqDCGbBNBUr+ud1Fvte0i1x6WIhGXS7
>> > qb5OTuljDicQ1L2mAKgvzl4XnOUsFmuBagZHYk58n19ZlxfBlyw=
>> > =gA3i
>> >
>> > -END PGP SIGNATURE-
>> >
>> > This results in a bad signature.
>> >
>>
>> What happens when you run:
>>
>> gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
>>
>> ?
>>
>
> $ gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
> gpg: keyserver option 'honor-http-proxy' is unknown
> gpg: les données signées sont supposées être dans «
> apache-log4j-2.15.0-bin.tar.gz »
> gpg: Signature faite le jeu 09 déc 2021 13:24:29 EST
> gpg:avec la clef RSA
> 53C935821AA6A755BD337DB53595395EB3D8E1BA
> gpg: MAUVAISE signature de « Ralph Goers (CODE SIGNING KEY) <
> rgo...@apache.org> » [inconnu]
>
> MAUVAISE=BAD
>
>
>> Gary
>>
>
>
apache-log4j-2.16.0 is out and this time signature and hash validation work
perfectly.

-
Daniel Savard

Re: log4j 2.15.0 signature and sha512 hash

[Daniel Savard]

-
Daniel Savard


Le lun. 13 déc. 2021 à 13:28, Gary Gregory  a
écrit :

> On Mon, Dec 13, 2021 at 1:22 PM Daniel Savard 
> wrote:
>
> > Le lun. 13 déc. 2021 à 12:34, Gary Gregory  a
> > écrit :
> >
> > > Works for me:
> > >
> > > gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
> > >
> >
> > Here is the content of the asc file:
> >
> > -BEGIN PGP SIGNATURE-
> >
> > iQIzBAABCgAdFiEEU8k1ghqmp1W9M321NZU5XrPY4boFAmGySd0ACgkQNZU5XrPY
> > 4bqQtQ/+KXQi3+6LZ13HyEefNsnBm84krCXK/nAIlRnerbV+Wj1g0xU7cC8l3m+n
> > UHw2/BIIurGnOKU4bvGUOc5UYDTED4LPadkvXYW0NMvBGla0fvR1lyEMypS2E2nz
> > 0g3sqHC0T4ZEGEIO7jmUVQJEpPya33VlztfnoNQPcqv6PCOilIVK1EmoewEBvnsd
> > SVAJPhJtD43mUPLsIMIc4k7IM56FssN+2+46mba6YH39C4Z4NheGBUK9UXWYKQd3
> > 3DKHoIoLb2hKXLdxHHz5u4dbkYPiHyGR4iX0wjq7W4eUX/4v+czsjrs8vQ5Gvhba
> > slg6RfUeu+fkMJfQUgRLT2HRSIKsuUd2QMppxW1GKRnfpx0yzAUWMfFfPcxuEa/u
> > em4YCsz1/a0AtfgtI6+Lne0yWsxORVVutquVOyF0ddjySQccPNYaOyOjx6jASM2A
> > LxkdCko0+2rSuIWcLMpWaoeRedao4L6O3azdU0IcN7/BVyXczM2t5cYB4QDdXvSc
> > UKJ6q6dQLngIwYqo6Q/d1XeKatWuhSPz0+mAoGAWvllvzWKb1/YbC/jZk/vxVqzR
> > K/mHB24pPWfcWiQNfbHrOVVUzv783u1RkEqDCGbBNBUr+ud1Fvte0i1x6WIhGXS7
> > qb5OTuljDicQ1L2mAKgvzl4XnOUsFmuBagZHYk58n19ZlxfBlyw=
> > =gA3i
> >
> > -END PGP SIGNATURE-
> >
> > This results in a bad signature.
> >
>
> What happens when you run:
>
> gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
>
> ?
>

$ gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
gpg: keyserver option 'honor-http-proxy' is unknown
gpg: les données signées sont supposées être dans «
apache-log4j-2.15.0-bin.tar.gz »
gpg: Signature faite le jeu 09 déc 2021 13:24:29 EST
gpg:avec la clef RSA
53C935821AA6A755BD337DB53595395EB3D8E1BA
gpg: MAUVAISE signature de « Ralph Goers (CODE SIGNING KEY) <
rgo...@apache.org> » [inconnu]

MAUVAISE=BAD


> Gary
>

---
Daniel Savard

Re: log4j 2.15.0 signature and sha512 hash

[Gary Gregory]

On Mon, Dec 13, 2021 at 1:22 PM Daniel Savard 
wrote:

> Le lun. 13 déc. 2021 à 12:34, Gary Gregory  a
> écrit :
>
> > Works for me:
> >
> > gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
> >
>
> Here is the content of the asc file:
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAABCgAdFiEEU8k1ghqmp1W9M321NZU5XrPY4boFAmGySd0ACgkQNZU5XrPY
> 4bqQtQ/+KXQi3+6LZ13HyEefNsnBm84krCXK/nAIlRnerbV+Wj1g0xU7cC8l3m+n
> UHw2/BIIurGnOKU4bvGUOc5UYDTED4LPadkvXYW0NMvBGla0fvR1lyEMypS2E2nz
> 0g3sqHC0T4ZEGEIO7jmUVQJEpPya33VlztfnoNQPcqv6PCOilIVK1EmoewEBvnsd
> SVAJPhJtD43mUPLsIMIc4k7IM56FssN+2+46mba6YH39C4Z4NheGBUK9UXWYKQd3
> 3DKHoIoLb2hKXLdxHHz5u4dbkYPiHyGR4iX0wjq7W4eUX/4v+czsjrs8vQ5Gvhba
> slg6RfUeu+fkMJfQUgRLT2HRSIKsuUd2QMppxW1GKRnfpx0yzAUWMfFfPcxuEa/u
> em4YCsz1/a0AtfgtI6+Lne0yWsxORVVutquVOyF0ddjySQccPNYaOyOjx6jASM2A
> LxkdCko0+2rSuIWcLMpWaoeRedao4L6O3azdU0IcN7/BVyXczM2t5cYB4QDdXvSc
> UKJ6q6dQLngIwYqo6Q/d1XeKatWuhSPz0+mAoGAWvllvzWKb1/YbC/jZk/vxVqzR
> K/mHB24pPWfcWiQNfbHrOVVUzv783u1RkEqDCGbBNBUr+ud1Fvte0i1x6WIhGXS7
> qb5OTuljDicQ1L2mAKgvzl4XnOUsFmuBagZHYk58n19ZlxfBlyw=
> =gA3i
>
> -END PGP SIGNATURE-
>
> This results in a bad signature.
>

What happens when you run:

gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc

?

Gary

>
>
> >
> > gpg: assuming signed data in 'apache-log4j-2.15.0-bin.tar.gz'
> > gpg: Signature made Thu Dec  9 13:24:29 2021 EST
> > gpg:using RSA key
> 53C935821AA6A755BD337DB53595395EB3D8E1BA
> > gpg: Good signature from "Ralph Goers (CODE SIGNING KEY) <
> > rgo...@apache.org>"
> > [unknown]
> > gpg: WARNING: This key is not certified with a trusted signature!
> > gpg:  There is no indication that the signature belongs to the
> > owner.
> > Primary key fingerprint: 53C9 3582 1AA6 A755 BD33  7DB5 3595 395E B3D8
> E1BA
> >
> > shasum -a512 apache-log4j-2.15.0-bin.tar.gz
> >
> >
> >
> c0e2d704d720bffc99520e5dfbf860ba3cb7f8a34c16a1caa8ce35618370ff06c19e3dc64fc258ad45d4308690551bf34b3ecb7acc0848aa12615f46398cda4a
> >  apache-log4j-2.15.0-bin.tar.gz
> >
> > is the same as the data in
> >
> >
> https://downloads.apache.org/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.tar.gz.sha512
> >
> >
> Here is the content of the file when I download it:
>
> apache-log4j-2.15.0-bin.tar.gz: C0E2D704 D720BFFC 99520E5D FBF860BA
> 3CB7F8A3
> 4C16A1CA A8CE3561 8370FF06 C19E3DC6
> 4FC258AD
> 45D43086 90551BF3 4B3ECB7A CC0848AA
> 12615F46
>
> 398CDA4A
>
>
> Obviously not a sha512 hash.
>
>
>
> >
> > Gary
> >
> >
> -
> Daniel Savard
>

Re: log4j 2.15.0 signature and sha512 hash

[Daniel Savard]

Le lun. 13 déc. 2021 à 12:23, Matt Sicker  a écrit :

> Did you import the keys from our keys file? That should make the
> signatures authenticate.
>

Of course.

-
Daniel Savard

Re: log4j 2.15.0 signature and sha512 hash

[Daniel Savard]

Le lun. 13 déc. 2021 à 12:34, Gary Gregory  a
écrit :

> Works for me:
>
> gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc
>

Here is the content of the asc file:

-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEU8k1ghqmp1W9M321NZU5XrPY4boFAmGySd0ACgkQNZU5XrPY
4bqQtQ/+KXQi3+6LZ13HyEefNsnBm84krCXK/nAIlRnerbV+Wj1g0xU7cC8l3m+n
UHw2/BIIurGnOKU4bvGUOc5UYDTED4LPadkvXYW0NMvBGla0fvR1lyEMypS2E2nz
0g3sqHC0T4ZEGEIO7jmUVQJEpPya33VlztfnoNQPcqv6PCOilIVK1EmoewEBvnsd
SVAJPhJtD43mUPLsIMIc4k7IM56FssN+2+46mba6YH39C4Z4NheGBUK9UXWYKQd3
3DKHoIoLb2hKXLdxHHz5u4dbkYPiHyGR4iX0wjq7W4eUX/4v+czsjrs8vQ5Gvhba
slg6RfUeu+fkMJfQUgRLT2HRSIKsuUd2QMppxW1GKRnfpx0yzAUWMfFfPcxuEa/u
em4YCsz1/a0AtfgtI6+Lne0yWsxORVVutquVOyF0ddjySQccPNYaOyOjx6jASM2A
LxkdCko0+2rSuIWcLMpWaoeRedao4L6O3azdU0IcN7/BVyXczM2t5cYB4QDdXvSc
UKJ6q6dQLngIwYqo6Q/d1XeKatWuhSPz0+mAoGAWvllvzWKb1/YbC/jZk/vxVqzR
K/mHB24pPWfcWiQNfbHrOVVUzv783u1RkEqDCGbBNBUr+ud1Fvte0i1x6WIhGXS7
qb5OTuljDicQ1L2mAKgvzl4XnOUsFmuBagZHYk58n19ZlxfBlyw=
=gA3i

-END PGP SIGNATURE-

This results in a bad signature.


>
> gpg: assuming signed data in 'apache-log4j-2.15.0-bin.tar.gz'
> gpg: Signature made Thu Dec  9 13:24:29 2021 EST
> gpg:using RSA key 53C935821AA6A755BD337DB53595395EB3D8E1BA
> gpg: Good signature from "Ralph Goers (CODE SIGNING KEY) <
> rgo...@apache.org>"
> [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 53C9 3582 1AA6 A755 BD33  7DB5 3595 395E B3D8 E1BA
>
> shasum -a512 apache-log4j-2.15.0-bin.tar.gz
>
>
> c0e2d704d720bffc99520e5dfbf860ba3cb7f8a34c16a1caa8ce35618370ff06c19e3dc64fc258ad45d4308690551bf34b3ecb7acc0848aa12615f46398cda4a
>  apache-log4j-2.15.0-bin.tar.gz
>
> is the same as the data in
>
> https://downloads.apache.org/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.tar.gz.sha512
>
>
Here is the content of the file when I download it:

apache-log4j-2.15.0-bin.tar.gz: C0E2D704 D720BFFC 99520E5D FBF860BA 3CB7F8A3
4C16A1CA A8CE3561 8370FF06 C19E3DC6 4FC258AD
45D43086 90551BF3 4B3ECB7A CC0848AA 12615F46

398CDA4A


Obviously not a sha512 hash.



>
> Gary
>
>
-
Daniel Savard

Re: log4j 2.15.0 signature and sha512 hash

[Gary Gregory]

Works for me:

gpg --verify apache-log4j-2.15.0-bin.tar.gz.asc

gpg: assuming signed data in 'apache-log4j-2.15.0-bin.tar.gz'
gpg: Signature made Thu Dec  9 13:24:29 2021 EST
gpg:using RSA key 53C935821AA6A755BD337DB53595395EB3D8E1BA
gpg: Good signature from "Ralph Goers (CODE SIGNING KEY) "
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 53C9 3582 1AA6 A755 BD33  7DB5 3595 395E B3D8 E1BA

shasum -a512 apache-log4j-2.15.0-bin.tar.gz

c0e2d704d720bffc99520e5dfbf860ba3cb7f8a34c16a1caa8ce35618370ff06c19e3dc64fc258ad45d4308690551bf34b3ecb7acc0848aa12615f46398cda4a
 apache-log4j-2.15.0-bin.tar.gz

is the same as the data in
https://downloads.apache.org/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.tar.gz.sha512

shasum --check -a512 apache-log4j-2.15.0-bin.tar.gz.sha512

I had to edit my local copy to match the format expected by shasum.

You can also use OpenSSL:

openssl dgst -sha512 apache-log4j-2.15.0-bin.tar.gz
SHA512(apache-log4j-2.15.0-bin.tar.gz)=
c0e2d704d720bffc99520e5dfbf860ba3cb7f8a34c16a1caa8ce35618370ff06c19e3dc64fc258ad45d4308690551bf34b3ecb7acc0848aa12615f46398cda4a

Gary


On Mon, Dec 13, 2021 at 11:52 AM Daniel Savard 
wrote:

> Hi everyone,
>
> I am trying to authenticate the log4j-2.15 code downloaded from the
> apache.org site and the sha512 file doesn't contain a sha512 hash at all
> and the signature file (.asc) failed to authenticate the parent file.
>
> Anyone can fix this? I cannot patch our system with unauthenticated code.
> Please, provide correct files and authentication files.
>
> Regards,
> -
> Daniel Savard
>

Re: log4j 2.15.0 signature and sha512 hash

[Matt Sicker]

Did you import the keys from our keys file? That should make the
signatures authenticate.

On Mon, Dec 13, 2021 at 10:52 AM Daniel Savard  wrote:
>
> Hi everyone,
>
> I am trying to authenticate the log4j-2.15 code downloaded from the
> apache.org site and the sha512 file doesn't contain a sha512 hash at all
> and the signature file (.asc) failed to authenticate the parent file.
>
> Anyone can fix this? I cannot patch our system with unauthenticated code.
> Please, provide correct files and authentication files.
>
> Regards,
> -
> Daniel Savard

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

Re: [log4j][log4j-web] Start and Stop Order?

[Gary Gregory]

I think that PR is not helpful for my use case.

Also in general, I push back PR like this one because it adds a whole new
class with ZERO Javadoc: Log4jShutdownOnContextDestroyedListener

Gary

On Wed, Feb 24, 2021, 11:47 Matt Sicker  wrote:

> https://github.com/apache/logging-log4j2/pull/463 added more to this
> feature. Might help fix your problem.
>
> On Wed, 24 Feb 2021 at 10:44, Gary Gregory  wrote:
> >
> > On Wed, Feb 24, 2021 at 11:37 AM Matt Sicker  wrote:
> > >
> > > This behavior was recently changed but not released yet.
> >
> > It has though:
> >
> > 2.14.0's log4j-web contains a web fragment xml configuration file that
> > says "I'm first". The problem is that I need (as does everyone I
> > claim) "I'm first" on start and "I'm last" on stop.
> >
> > Or am I missing something?
> >
> > Gary
> >
> > >
> > > On Wed, 24 Feb 2021 at 10:07, Ralph Goers 
> wrote:
> > > >
> > > > Interesting that you posted this to the user list.
> > > >
> > > > Last I checked the way the shutdown worked was very much dependent
> on which servlet spec version the app is using. As I recall, prior to 3.0 a
> servlet filter had to be directly configured by the user. Configuring that
> in the web.xml as the first filter pretty much guaranteed proper ordering.
> With 3.0 I believe a ServletContainerInitializer is used instead to
> register the filter. I believe the ordering of that is only guaranteed if
> Log4j’s ServletContainerInitializer is called before any others.
> > > >
> > > > Ralph
> > > >
> > > > > On Feb 24, 2021, at 7:20 AM, Gary Gregory 
> wrote:
> > > > >
> > > > > Hi All:
> > > > >
> > > > > I have a bug in a web app where I use log4j-web:
> > > > > - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app,
> which is correct.
> > > > > - The App runs and uses Log4j 2
> > > > > - When I stop or undeploy the web app, Tomcat complains about a
> Log4j
> > > > > thread still hanging around because:
> > > > > - Tomcat stops Log4j FIRST (which is wrong for this stack).
> > > > > - Tomcat stops the web-app which cause some logging
> > > > > - Log4j re-initializes itself
> > > > >
> > > > > So... Can we fix this in our web fragment? Can we say "start first
> and
> > > > > stop last"?
> > > > >
> > > > > Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10)
> help?
> > > > >
> > > > > TY!
> > > > > Gary
> > > > >
> > > > >
> -
> > > > > 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
> >
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: [log4j][log4j-web] Start and Stop Order?

[Ralph Goers]

I’m first on start should always imply I am last on stop.

I am not aware of the web fragment support that was added.

Ralph

> On Feb 24, 2021, at 9:44 AM, Gary Gregory  wrote:
> 
> On Wed, Feb 24, 2021 at 11:37 AM Matt Sicker  wrote:
>> 
>> This behavior was recently changed but not released yet.
> 
> It has though:
> 
> 2.14.0's log4j-web contains a web fragment xml configuration file that
> says "I'm first". The problem is that I need (as does everyone I
> claim) "I'm first" on start and "I'm last" on stop.
> 
> Or am I missing something?
> 
> Gary
> 
>> 
>> On Wed, 24 Feb 2021 at 10:07, Ralph Goers  wrote:
>>> 
>>> Interesting that you posted this to the user list.
>>> 
>>> Last I checked the way the shutdown worked was very much dependent on which 
>>> servlet spec version the app is using. As I recall, prior to 3.0 a servlet 
>>> filter had to be directly configured by the user. Configuring that in the 
>>> web.xml as the first filter pretty much guaranteed proper ordering. With 
>>> 3.0 I believe a ServletContainerInitializer is used instead to register the 
>>> filter. I believe the ordering of that is only guaranteed if Log4j’s 
>>> ServletContainerInitializer is called before any others.
>>> 
>>> Ralph
>>> 
 On Feb 24, 2021, at 7:20 AM, Gary Gregory  wrote:
 
 Hi All:
 
 I have a bug in a web app where I use log4j-web:
 - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app, which is 
 correct.
 - The App runs and uses Log4j 2
 - When I stop or undeploy the web app, Tomcat complains about a Log4j
 thread still hanging around because:
 - Tomcat stops Log4j FIRST (which is wrong for this stack).
 - Tomcat stops the web-app which cause some logging
 - Log4j re-initializes itself
 
 So... Can we fix this in our web fragment? Can we say "start first and
 stop last"?
 
 Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10) help?
 
 TY!
 Gary
 
 -
 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
> 
> 



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

Re: [log4j][log4j-web] Start and Stop Order?

[Gary Gregory]

On Wed, Feb 24, 2021 at 11:07 AM Ralph Goers  wrote:
>
> Interesting that you posted this to the user list.

I'm a real user in this case :-)

>
> Last I checked the way the shutdown worked was very much dependent on which 
> servlet spec version the app is using. As I recall, prior to 3.0 a servlet 
> filter had to be directly configured by the user. Configuring that in the 
> web.xml as the first filter pretty much guaranteed proper ordering. With 3.0 
> I believe a ServletContainerInitializer is used instead to register the 
> filter. I believe the ordering of that is only guaranteed if Log4j’s 
> ServletContainerInitializer is called before any others.

I'm using Tomcat 9 just because that is the use case of our QA today
and I'm happy to use Tomcat 10 instead.

I am trying to find a way to get our web fragment to behave which is
really a dev-ML topic ;-)

I will try to hardwire Log4j shutdown from our own servlets...

Gary

>
> Ralph
>
> > On Feb 24, 2021, at 7:20 AM, Gary Gregory  wrote:
> >
> > Hi All:
> >
> > I have a bug in a web app where I use log4j-web:
> > - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app, which is 
> > correct.
> > - The App runs and uses Log4j 2
> > - When I stop or undeploy the web app, Tomcat complains about a Log4j
> > thread still hanging around because:
> > - Tomcat stops Log4j FIRST (which is wrong for this stack).
> > - Tomcat stops the web-app which cause some logging
> > - Log4j re-initializes itself
> >
> > So... Can we fix this in our web fragment? Can we say "start first and
> > stop last"?
> >
> > Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10) help?
> >
> > TY!
> > Gary
> >
> > -
> > 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][log4j-web] Start and Stop Order?

[Matt Sicker]

https://github.com/apache/logging-log4j2/pull/463 added more to this
feature. Might help fix your problem.

On Wed, 24 Feb 2021 at 10:44, Gary Gregory  wrote:
>
> On Wed, Feb 24, 2021 at 11:37 AM Matt Sicker  wrote:
> >
> > This behavior was recently changed but not released yet.
>
> It has though:
>
> 2.14.0's log4j-web contains a web fragment xml configuration file that
> says "I'm first". The problem is that I need (as does everyone I
> claim) "I'm first" on start and "I'm last" on stop.
>
> Or am I missing something?
>
> Gary
>
> >
> > On Wed, 24 Feb 2021 at 10:07, Ralph Goers  
> > wrote:
> > >
> > > Interesting that you posted this to the user list.
> > >
> > > Last I checked the way the shutdown worked was very much dependent on 
> > > which servlet spec version the app is using. As I recall, prior to 3.0 a 
> > > servlet filter had to be directly configured by the user. Configuring 
> > > that in the web.xml as the first filter pretty much guaranteed proper 
> > > ordering. With 3.0 I believe a ServletContainerInitializer is used 
> > > instead to register the filter. I believe the ordering of that is only 
> > > guaranteed if Log4j’s ServletContainerInitializer is called before any 
> > > others.
> > >
> > > Ralph
> > >
> > > > On Feb 24, 2021, at 7:20 AM, Gary Gregory  
> > > > wrote:
> > > >
> > > > Hi All:
> > > >
> > > > I have a bug in a web app where I use log4j-web:
> > > > - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app, which is 
> > > > correct.
> > > > - The App runs and uses Log4j 2
> > > > - When I stop or undeploy the web app, Tomcat complains about a Log4j
> > > > thread still hanging around because:
> > > > - Tomcat stops Log4j FIRST (which is wrong for this stack).
> > > > - Tomcat stops the web-app which cause some logging
> > > > - Log4j re-initializes itself
> > > >
> > > > So... Can we fix this in our web fragment? Can we say "start first and
> > > > stop last"?
> > > >
> > > > Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10) help?
> > > >
> > > > TY!
> > > > Gary
> > > >
> > > > -
> > > > 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
>

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

Re: [log4j][log4j-web] Start and Stop Order?

[Gary Gregory]

On Wed, Feb 24, 2021 at 11:37 AM Matt Sicker  wrote:
>
> This behavior was recently changed but not released yet.

It has though:

2.14.0's log4j-web contains a web fragment xml configuration file that
says "I'm first". The problem is that I need (as does everyone I
claim) "I'm first" on start and "I'm last" on stop.

Or am I missing something?

Gary

>
> On Wed, 24 Feb 2021 at 10:07, Ralph Goers  wrote:
> >
> > Interesting that you posted this to the user list.
> >
> > Last I checked the way the shutdown worked was very much dependent on which 
> > servlet spec version the app is using. As I recall, prior to 3.0 a servlet 
> > filter had to be directly configured by the user. Configuring that in the 
> > web.xml as the first filter pretty much guaranteed proper ordering. With 
> > 3.0 I believe a ServletContainerInitializer is used instead to register the 
> > filter. I believe the ordering of that is only guaranteed if Log4j’s 
> > ServletContainerInitializer is called before any others.
> >
> > Ralph
> >
> > > On Feb 24, 2021, at 7:20 AM, Gary Gregory  wrote:
> > >
> > > Hi All:
> > >
> > > I have a bug in a web app where I use log4j-web:
> > > - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app, which is 
> > > correct.
> > > - The App runs and uses Log4j 2
> > > - When I stop or undeploy the web app, Tomcat complains about a Log4j
> > > thread still hanging around because:
> > > - Tomcat stops Log4j FIRST (which is wrong for this stack).
> > > - Tomcat stops the web-app which cause some logging
> > > - Log4j re-initializes itself
> > >
> > > So... Can we fix this in our web fragment? Can we say "start first and
> > > stop last"?
> > >
> > > Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10) help?
> > >
> > > TY!
> > > Gary
> > >
> > > -
> > > 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: [log4j][log4j-web] Start and Stop Order?

[Matt Sicker]

This behavior was recently changed but not released yet.

On Wed, 24 Feb 2021 at 10:07, Ralph Goers  wrote:
>
> Interesting that you posted this to the user list.
>
> Last I checked the way the shutdown worked was very much dependent on which 
> servlet spec version the app is using. As I recall, prior to 3.0 a servlet 
> filter had to be directly configured by the user. Configuring that in the 
> web.xml as the first filter pretty much guaranteed proper ordering. With 3.0 
> I believe a ServletContainerInitializer is used instead to register the 
> filter. I believe the ordering of that is only guaranteed if Log4j’s 
> ServletContainerInitializer is called before any others.
>
> Ralph
>
> > On Feb 24, 2021, at 7:20 AM, Gary Gregory  wrote:
> >
> > Hi All:
> >
> > I have a bug in a web app where I use log4j-web:
> > - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app, which is 
> > correct.
> > - The App runs and uses Log4j 2
> > - When I stop or undeploy the web app, Tomcat complains about a Log4j
> > thread still hanging around because:
> > - Tomcat stops Log4j FIRST (which is wrong for this stack).
> > - Tomcat stops the web-app which cause some logging
> > - Log4j re-initializes itself
> >
> > So... Can we fix this in our web fragment? Can we say "start first and
> > stop last"?
> >
> > Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10) help?
> >
> > TY!
> > Gary
> >
> > -
> > 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][log4j-web] Start and Stop Order?

[Ralph Goers]

Interesting that you posted this to the user list.

Last I checked the way the shutdown worked was very much dependent on which 
servlet spec version the app is using. As I recall, prior to 3.0 a servlet 
filter had to be directly configured by the user. Configuring that in the 
web.xml as the first filter pretty much guaranteed proper ordering. With 3.0 I 
believe a ServletContainerInitializer is used instead to register the filter. I 
believe the ordering of that is only guaranteed if Log4j’s 
ServletContainerInitializer is called before any others. 

Ralph

> On Feb 24, 2021, at 7:20 AM, Gary Gregory  wrote:
> 
> Hi All:
> 
> I have a bug in a web app where I use log4j-web:
> - Tomcat 9 correctly starts Log4j 2 FIRST, BEFORE the web-app, which is 
> correct.
> - The App runs and uses Log4j 2
> - When I stop or undeploy the web app, Tomcat complains about a Log4j
> thread still hanging around because:
> - Tomcat stops Log4j FIRST (which is wrong for this stack).
> - Tomcat stops the web-app which cause some logging
> - Log4j re-initializes itself
> 
> So... Can we fix this in our web fragment? Can we say "start first and
> stop last"?
> 
> Can I say that at all in server.xml? Does Servlet 5.0 (Tomcat 10) help?
> 
> TY!
> Gary
> 
> -
> 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 3.0.0-SNAHSOPT disappeared

[Ralph Goers]

Unfortunately, I don’t see 2.x as ever fully supporting the JPMS. I keep 
wanting to focus solely on 3.0 to get it released but there is still so much 
work to do that it is difficult since we can’t put everything on hold until 
then.

Ralph

> On Nov 3, 2020, at 8:57 AM, Oliver Kopp  wrote:
> 
> Hi,
> 
> Sure. I think, we thought, fixing snapshot usage issues (and possibly
> report back issues) would help log4j more than staying with a pinned
> snapshot.
> 
> Surely, this will cause troubles when initiating a release for Debian.
> Maybe a 3.0.0 release happens before all other dependencies of our project
> are packaged for Debian 😅
> 
> Cheers,
> 
> Oliver
> 
> Ralph Goers  schrieb am Di., 3. Nov. 2020,
> 16:52:
> 
>> Snapshots are not releases and we don’t guarantee we won’t make breaking
>> changes. If you want to use 3.0.0 in a production environment you should
>> clone the repo locally and create a tag and create an internal release for
>> yourself.  You should also use a version number that won’t conflict with
>> our releases by using a version number like 3.0.0-mycorp-1.
>> 
>> Ralph
>> 
>>> On Nov 3, 2020, at 4:34 AM, Oliver Kopp  wrote:
>>> 
>>> Hi,
>>> 
>>> Due to
>> https://issues.apache.org/jira/browse/LOG4J2-2690?focusedCommentId=16927936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16927936
>>> we are using 3.0.0-SNAPSHOT in our Java 15 project.
>>> 
>>> This morning, we noticed that maven-metadata.xml disappeared from
>>> 
>> https://repository.apache.org/snapshots/org/apache/logging/log4j/log4j-jcl/3.0.0-SNAPSHOT/
>>> and all mirrors. This makes our software JabRef
>>> (https://github.com/jabref/jabref/) non-buildadble.
>>> 
>>> Would it be possible to bring back 3.0.0-SNAPSHOT to the apache maven
>>> repository?
>>> 
>>> Thank you in advance and greetings,
>>> 
>>> Oliver
>>> --
>>> https://github.com/koppor/
>>> 
>>> -
>>> 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 3.0.0-SNAHSOPT disappeared

[Oliver Kopp]

Hi,

Sure. I think, we thought, fixing snapshot usage issues (and possibly
report back issues) would help log4j more than staying with a pinned
snapshot.

Surely, this will cause troubles when initiating a release for Debian.
Maybe a 3.0.0 release happens before all other dependencies of our project
are packaged for Debian 😅

Cheers,

Oliver

Ralph Goers  schrieb am Di., 3. Nov. 2020,
16:52:

> Snapshots are not releases and we don’t guarantee we won’t make breaking
> changes. If you want to use 3.0.0 in a production environment you should
> clone the repo locally and create a tag and create an internal release for
> yourself.  You should also use a version number that won’t conflict with
> our releases by using a version number like 3.0.0-mycorp-1.
>
> Ralph
>
> > On Nov 3, 2020, at 4:34 AM, Oliver Kopp  wrote:
> >
> > Hi,
> >
> > Due to
> https://issues.apache.org/jira/browse/LOG4J2-2690?focusedCommentId=16927936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16927936
> > we are using 3.0.0-SNAPSHOT in our Java 15 project.
> >
> > This morning, we noticed that maven-metadata.xml disappeared from
> >
> https://repository.apache.org/snapshots/org/apache/logging/log4j/log4j-jcl/3.0.0-SNAPSHOT/
> > and all mirrors. This makes our software JabRef
> > (https://github.com/jabref/jabref/) non-buildadble.
> >
> > Would it be possible to bring back 3.0.0-SNAPSHOT to the apache maven
> > repository?
> >
> > Thank you in advance and greetings,
> >
> > Oliver
> > --
> > https://github.com/koppor/
> >
> > -
> > 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 3.0.0-SNAHSOPT disappeared

[Oliver Kopp]

Hi,

Matt Sicker  schrieb am Di., 3. Nov. 2020, 15:23:

I’m not particularly sure why you’ve chosen 3.x


Because our issue seems not to be solved for the 2.x release according to
the state of LOG4J2-2690 -
https://issues.apache.org/jira/browse/LOG4J2-2690?focusedCommentId=16927936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16927936
.

Maybe I'm wrong and we should try the latest 2.x release.

Cheers,

Oliver

Re: log4j 3.0.0-SNAHSOPT disappeared

[Ralph Goers]

Snapshots are not releases and we don’t guarantee we won’t make breaking 
changes. If you want to use 3.0.0 in a production environment you should clone 
the repo locally and create a tag and create an internal release for yourself.  
You should also use a version number that won’t conflict with our releases by 
using a version number like 3.0.0-mycorp-1.

Ralph

> On Nov 3, 2020, at 4:34 AM, Oliver Kopp  wrote:
> 
> Hi,
> 
> Due to 
> https://issues.apache.org/jira/browse/LOG4J2-2690?focusedCommentId=16927936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16927936
> we are using 3.0.0-SNAPSHOT in our Java 15 project.
> 
> This morning, we noticed that maven-metadata.xml disappeared from
> https://repository.apache.org/snapshots/org/apache/logging/log4j/log4j-jcl/3.0.0-SNAPSHOT/
> and all mirrors. This makes our software JabRef
> (https://github.com/jabref/jabref/) non-buildadble.
> 
> Would it be possible to bring back 3.0.0-SNAPSHOT to the apache maven
> repository?
> 
> Thank you in advance and greetings,
> 
> Oliver
> --
> https://github.com/koppor/
> 
> -
> 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 3.0.0-SNAHSOPT disappeared

[Matt Sicker]

Oops, sent too soon. I see that’s a snapshot repo. I believe we need to run
CI again since we purged some old snapshots the other day.

On Tue, Nov 3, 2020 at 08:23 Matt Sicker  wrote:

> Snapshots aren’t meant to be in the release repository. While we do
> publish snapshots in our snapshots repo from CI, those aren’t releases, so
> we don’t directly advertise them except to users who want to test out
> future changes. I’m not particularly sure why you’ve chosen 3.x as that
> repo changes more drastically than the 2.x one (except for the API module).
>
> On Tue, Nov 3, 2020 at 05:35 Oliver Kopp  wrote:
>
>> Hi,
>>
>> Due to
>> https://issues.apache.org/jira/browse/LOG4J2-2690?focusedCommentId=16927936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16927936
>> we are using 3.0.0-SNAPSHOT in our Java 15 project.
>>
>> This morning, we noticed that maven-metadata.xml disappeared from
>>
>> https://repository.apache.org/snapshots/org/apache/logging/log4j/log4j-jcl/3.0.0-SNAPSHOT/
>> and all mirrors. This makes our software JabRef
>> (https://github.com/jabref/jabref/) non-buildadble.
>>
>> Would it be possible to bring back 3.0.0-SNAPSHOT to the apache maven
>> repository?
>>
>> Thank you in advance and greetings,
>>
>> Oliver
>> --
>> https://github.com/koppor/
>>
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>>

Re: log4j 3.0.0-SNAHSOPT disappeared

[Matt Sicker]

Snapshots aren’t meant to be in the release repository. While we do publish
snapshots in our snapshots repo from CI, those aren’t releases, so we don’t
directly advertise them except to users who want to test out future
changes. I’m not particularly sure why you’ve chosen 3.x as that repo
changes more drastically than the 2.x one (except for the API module).

On Tue, Nov 3, 2020 at 05:35 Oliver Kopp  wrote:

> Hi,
>
> Due to
> https://issues.apache.org/jira/browse/LOG4J2-2690?focusedCommentId=16927936&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16927936
> we are using 3.0.0-SNAPSHOT in our Java 15 project.
>
> This morning, we noticed that maven-metadata.xml disappeared from
>
> https://repository.apache.org/snapshots/org/apache/logging/log4j/log4j-jcl/3.0.0-SNAPSHOT/
> and all mirrors. This makes our software JabRef
> (https://github.com/jabref/jabref/) non-buildadble.
>
> Would it be possible to bring back 3.0.0-SNAPSHOT to the apache maven
> repository?
>
> Thank you in advance and greetings,
>
> Oliver
> --
> https://github.com/koppor/
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Log4j Syslog

[Ralph Goers]

1. Please not that the paragraph after your signature is meaningless when 
posting to a publicly archived mailing list such as this one. 
2. The pattern attribute needs to be a valid pattern “RFC 5424” is not a valid 
pattern. I would assume that you really should have specified 
layout.type=RFC5424Layout.
3. The SSL configuration needs to be defined as a subcomponent of the appender 
such as 
appender.syslogELM.SSL.protocol=TLS
appender.syslogELM.SSL.KeyStore.location=path/to/keystore

etc.

Ralph

> On Nov 15, 2019, at 8:33 AM, vimochan.cheethir...@cslbehring.com wrote:
> 
> Hello guys,
> 
> Not sure if this is a right forum, but trying my luck.
> 
> I am trying to use a properties file to enable my application to send syslog 
> events to our ELM over SSL/TLS. I have installed my cert in the keystore, it 
> looks like its not working…can anyone verify if these entries make sense.
> 
> appender.syslogELM.type=syslog
> appender.syslogELM.name=syslogELM
> appender.syslogELM.host=**myhostname
> appender.syslogELM.port=6514
> appender.syslogELM.protocol=TCP
> appender.syslogELM.layout.type=PatternLayout
> appender.syslogELM.layout.pattern=RFC 5424
> appender.syslogELM.facility=LOCAL7
> appender.syslogELM.SSL=ELMSSL
> 
> SSL.ELMSSL.name=core.net.ssl.SslConfiguration
> SSL.ELMSSL.protocol=TLS
> SSL.ELMSSL.KeyStore.location=**path to /.keystore
> SSL.ELMSSL.KeyStore.password=**mypwd
> SSL.ELMSSL.TrustStore.location=**path to /.keystore
> SSL.ELMSSL.TrustStore.password=**mypwd
> 
> Log files throw and error saying that “syslog contains an invalid element or 
> attribute "SSL””, Can you one help me with this?
> 
> Thanks
> 
> 
> This email, including any attachments, is confidential and contains 
> proprietary content and may be legally privileged. This transmission is 
> intended only for the designated recipient(s), and any duplication or 
> distribution, in any form or part, without the written consent of the sender 
> is strictly prohibited. These confidentiality protections apply even if you 
> received this transmission in error, in which case you should delete the 
> message, disregard its contents and notify the sender of the mistake. CSL 
> Behring
> 
> -
> 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 2.10 / slf4j 1.8 icw OSGI/Eclipse

[Rob Gansevles]

Hi Ralph,

I have a simple osgi plugin that just logs something to slf4j Logger in the
Activator's bundle start method.
When I install and start log4j-core-2.11.0.jar, log4j-api-2.11.0.jar,
log4j-slf4j-impl-2.11.0.jar
and slf4j-api-1.8.0-beta1.jar in a clean felix gogo shell, and then install
and start my plugin, it prints the No-SLF4J-providers-were-found message.

Should this not work out-of-the-box?
It does work if I do the same with log4j  2.9.1 and slf4j-api-1.7.25.

You can find my simple plugin on github: https://github.com/
rgansevles/osgi-slf4j-sample

Thanks in advance for looking into this,

Rob


On Thu, Feb 22, 2018 at 12:10 AM, Ralph Goers 
wrote:

> We have some unit tests that run to test our OSGi support and they are all
> passing. I don’t have anything that uses OSGi but I suppose if I can find a
> sample project I could give it a whirl. I just don’t know when. Between
> work and the other things I am trying to do for logging I don’t have much
> time.  I’ll take a look at that link.
>
> Ralph
>
> > On Feb 21, 2018, at 3:37 PM, Rob Gansevles  wrote:
> >
> > Ralph,
> >
> > Do you think that release 2.10 broke OSGI support?
> > Maybe you can try it out if you have time.
> >
> > It could be that the manifest has to be modified as described here:
> > http://aries.apache.org/modules/spi-fly.html#specconf
> > In that case i guess slf4j also needs to be changed.
> >
> > Rob
> >
> >
> > On Wed, Feb 21, 2018 at 2:12 AM, Ralph Goers  >
> > wrote:
> >
> >> I implemented the bindings for SLF4J 1.8 and they are in 2.10.0 but I
> have
> >> never tried it with OSGi.
> >>
> >> Ralph
> >>
> >>> On Feb 20, 2018, at 12:47 PM, Rob Gansevles 
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am trying to get Log4j 2.10 with slf4j 1.8 working in my eclipse
> plugin
> >>> project.
> >>>
> >>> Slf4j 1.8 does not use the StaticLoggerBinder method anymore and it
> seems
> >>> to me osgi was depending on that.
> >>> It worked fine with Log4j 2.9 and slf4j 1.7
> >>>
> >>> The error I get is the No-SLF4J-providers-were-found message.
> >>>
> >>> So my question is, Is this a supported combination in an OSGI
> >> environment?
> >>>
> >>> Thanks,
> >>>
> >>> Rob
> >>
> >>
> >>
> >> -
> >> 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 2.10 / slf4j 1.8 icw OSGI/Eclipse

[Ralph Goers]

We have some unit tests that run to test our OSGi support and they are all 
passing. I don’t have anything that uses OSGi but I suppose if I can find a 
sample project I could give it a whirl. I just don’t know when. Between work 
and the other things I am trying to do for logging I don’t have much time.  
I’ll take a look at that link.

Ralph

> On Feb 21, 2018, at 3:37 PM, Rob Gansevles  wrote:
> 
> Ralph,
> 
> Do you think that release 2.10 broke OSGI support?
> Maybe you can try it out if you have time.
> 
> It could be that the manifest has to be modified as described here:
> http://aries.apache.org/modules/spi-fly.html#specconf
> In that case i guess slf4j also needs to be changed.
> 
> Rob
> 
> 
> On Wed, Feb 21, 2018 at 2:12 AM, Ralph Goers 
> wrote:
> 
>> I implemented the bindings for SLF4J 1.8 and they are in 2.10.0 but I have
>> never tried it with OSGi.
>> 
>> Ralph
>> 
>>> On Feb 20, 2018, at 12:47 PM, Rob Gansevles 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I am trying to get Log4j 2.10 with slf4j 1.8 working in my eclipse plugin
>>> project.
>>> 
>>> Slf4j 1.8 does not use the StaticLoggerBinder method anymore and it seems
>>> to me osgi was depending on that.
>>> It worked fine with Log4j 2.9 and slf4j 1.7
>>> 
>>> The error I get is the No-SLF4J-providers-were-found message.
>>> 
>>> So my question is, Is this a supported combination in an OSGI
>> environment?
>>> 
>>> Thanks,
>>> 
>>> Rob
>> 
>> 
>> 
>> -
>> 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 2.10 / slf4j 1.8 icw OSGI/Eclipse

[Rob Gansevles]

Ralph,

Do you think that release 2.10 broke OSGI support?
Maybe you can try it out if you have time.

It could be that the manifest has to be modified as described here:
http://aries.apache.org/modules/spi-fly.html#specconf
In that case i guess slf4j also needs to be changed.

Rob


On Wed, Feb 21, 2018 at 2:12 AM, Ralph Goers 
wrote:

> I implemented the bindings for SLF4J 1.8 and they are in 2.10.0 but I have
> never tried it with OSGi.
>
> Ralph
>
> > On Feb 20, 2018, at 12:47 PM, Rob Gansevles 
> wrote:
> >
> > Hi,
> >
> > I am trying to get Log4j 2.10 with slf4j 1.8 working in my eclipse plugin
> > project.
> >
> > Slf4j 1.8 does not use the StaticLoggerBinder method anymore and it seems
> > to me osgi was depending on that.
> > It worked fine with Log4j 2.9 and slf4j 1.7
> >
> > The error I get is the No-SLF4J-providers-were-found message.
> >
> > So my question is, Is this a supported combination in an OSGI
> environment?
> >
> > Thanks,
> >
> > Rob
>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Log4j 2.10 / slf4j 1.8 icw OSGI/Eclipse

[Ralph Goers]

I implemented the bindings for SLF4J 1.8 and they are in 2.10.0 but I have 
never tried it with OSGi.

Ralph

> On Feb 20, 2018, at 12:47 PM, Rob Gansevles  wrote:
> 
> Hi,
> 
> I am trying to get Log4j 2.10 with slf4j 1.8 working in my eclipse plugin
> project.
> 
> Slf4j 1.8 does not use the StaticLoggerBinder method anymore and it seems
> to me osgi was depending on that.
> It worked fine with Log4j 2.9 and slf4j 1.7
> 
> The error I get is the No-SLF4J-providers-were-found message.
> 
> So my question is, Is this a supported combination in an OSGI environment?
> 
> Thanks,
> 
> Rob



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

Re: Log4j Migration from 1.x to 2.x

[Ralph Goers]

According to 
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/helpers/LogLog.html
 

 that class is used to log stuff internal to Log4j. Log4j 2 uses the 
StatusLogger for this. StatusLogger uses the Log4j API but has limited output 
control. You can find documentation on it at 
http://logging.apache.org/log4j/2.x/manual/configuration.html#StatusMessages 
. 
However, this is intended to only be used by Appenders, Filters or other Log4j 
plugins you create.

If you want to log exceptions you should just use 

logger.error(“The error thrown during the process: “, ex);

Debug and warning messages should be:

logger.debug(“Listening on port {}”, port);
logger.warn(“Could not find class - {}”, className);

After looking at FileWatchDog, Log4j 2 doesn’t have a class that you could use 
to monitor any arbitrary file. It does have a FileWatcher interface that is 
used to monitor the configuration files. You can register a 
ConfigurationListener that will have its onChange method called when the 
configuration is changed.

Ralph

> On Dec 19, 2017, at 4:29 PM, Praveen Kumar Gunasekaran 
>  wrote:
> 
> Ralph,
> 
> Sure. One of the examples that i can give as of now is for LogLog class.
> 
> We use LogLog class for exception handling. For any issues thrown during
> the logic, we catch the exception and throw the error using LogLog like
> below,
> 
>LogLog.error( "The error thrown during the process: ."
> );
> 
> We also use for handling debug and warning information which will help the
> developers,
> 
>LogLog.debug("Listening on port " + port);
>LogLog.warn("Could not find class - ");
> 
> 
> Thanks,
> Praveen Kumar
> 
> On Wed, Dec 20, 2017 at 2:43 AM, Ralph Goers 
> wrote:
> 
>> I will give the same answer I gave to another user just last week.
>> 
>> You are better off telling us what you are trying to achieve then asking
>> questions like below. Log4j 2 works very differently than Log4j 1 and has
>> more capabilities built in. It is better to take advantage of that then
>> simply trying to convert code line by line or function by function.
>> 
>> Ralph
>> 
>>> On Dec 19, 2017, at 2:09 PM, Praveen Kumar Gunasekaran <
>> praveenkumarg...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I am working on migrating our application from Log4J 1.2.15 version to
>>> latest Log4J 2.10 version. I did look into the documentation for
>> migration
>>> 
>>> https://logging.apache.org/log4j/2.x/manual/migration.html
>>> 
>>> The above link helped me in some of the issues but still i am not able to
>>> find the replacement for class files like,
>>> 
>>> org.apache.log4j.helpers.LogLog
>>> org.apache.log4j.helpers.FileWatchdog
>>> 
>>> and few more.
>>> 
>>> I would like to know if there is any mapping documentation available for
>>> 1.x classes to 2.x classes? Please do the needful.
>>> 
>>> Thanks,
>>> Praveen Kumar
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>> 

Re: Log4j Migration from 1.x to 2.x

[Matt Sicker]

Is LogLog just an event logger? There's a new EventLogger API that lets you
log generic events.

Another option might be to use Lombok and add @Log4j2 to your class to get
a logger field automatically.

On 19 December 2017 at 17:29, Praveen Kumar Gunasekaran <
praveenkumarg...@gmail.com> wrote:

> Ralph,
>
> Sure. One of the examples that i can give as of now is for LogLog class.
>
> We use LogLog class for exception handling. For any issues thrown during
> the logic, we catch the exception and throw the error using LogLog like
> below,
>
> LogLog.error( "The error thrown during the process: ."
> );
>
> We also use for handling debug and warning information which will help the
> developers,
>
> LogLog.debug("Listening on port " + port);
> LogLog.warn("Could not find class - ");
>
>
> Thanks,
> Praveen Kumar
>
> On Wed, Dec 20, 2017 at 2:43 AM, Ralph Goers 
> wrote:
>
> > I will give the same answer I gave to another user just last week.
> >
> > You are better off telling us what you are trying to achieve then asking
> > questions like below. Log4j 2 works very differently than Log4j 1 and has
> > more capabilities built in. It is better to take advantage of that then
> > simply trying to convert code line by line or function by function.
> >
> > Ralph
> >
> > > On Dec 19, 2017, at 2:09 PM, Praveen Kumar Gunasekaran <
> > praveenkumarg...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I am working on migrating our application from Log4J 1.2.15 version to
> > > latest Log4J 2.10 version. I did look into the documentation for
> > migration
> > >
> > > https://logging.apache.org/log4j/2.x/manual/migration.html
> > >
> > > The above link helped me in some of the issues but still i am not able
> to
> > > find the replacement for class files like,
> > >
> > > org.apache.log4j.helpers.LogLog
> > > org.apache.log4j.helpers.FileWatchdog
> > >
> > > and few more.
> > >
> > > I would like to know if there is any mapping documentation available
> for
> > > 1.x classes to 2.x classes? Please do the needful.
> > >
> > > Thanks,
> > > Praveen Kumar
> >
> >
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: Log4j Migration from 1.x to 2.x

[Praveen Kumar Gunasekaran]

Ralph,

Sure. One of the examples that i can give as of now is for LogLog class.

We use LogLog class for exception handling. For any issues thrown during
the logic, we catch the exception and throw the error using LogLog like
below,

LogLog.error( "The error thrown during the process: ."
);

We also use for handling debug and warning information which will help the
developers,

LogLog.debug("Listening on port " + port);
LogLog.warn("Could not find class - ");


Thanks,
Praveen Kumar

On Wed, Dec 20, 2017 at 2:43 AM, Ralph Goers 
wrote:

> I will give the same answer I gave to another user just last week.
>
> You are better off telling us what you are trying to achieve then asking
> questions like below. Log4j 2 works very differently than Log4j 1 and has
> more capabilities built in. It is better to take advantage of that then
> simply trying to convert code line by line or function by function.
>
> Ralph
>
> > On Dec 19, 2017, at 2:09 PM, Praveen Kumar Gunasekaran <
> praveenkumarg...@gmail.com> wrote:
> >
> > Hi,
> >
> > I am working on migrating our application from Log4J 1.2.15 version to
> > latest Log4J 2.10 version. I did look into the documentation for
> migration
> >
> > https://logging.apache.org/log4j/2.x/manual/migration.html
> >
> > The above link helped me in some of the issues but still i am not able to
> > find the replacement for class files like,
> >
> > org.apache.log4j.helpers.LogLog
> > org.apache.log4j.helpers.FileWatchdog
> >
> > and few more.
> >
> > I would like to know if there is any mapping documentation available for
> > 1.x classes to 2.x classes? Please do the needful.
> >
> > Thanks,
> > Praveen Kumar
>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Log4j Migration from 1.x to 2.x

[Ralph Goers]

I will give the same answer I gave to another user just last week.

You are better off telling us what you are trying to achieve then asking 
questions like below. Log4j 2 works very differently than Log4j 1 and has more 
capabilities built in. It is better to take advantage of that then simply 
trying to convert code line by line or function by function.

Ralph

> On Dec 19, 2017, at 2:09 PM, Praveen Kumar Gunasekaran 
>  wrote:
> 
> Hi,
> 
> I am working on migrating our application from Log4J 1.2.15 version to
> latest Log4J 2.10 version. I did look into the documentation for migration
> 
> https://logging.apache.org/log4j/2.x/manual/migration.html
> 
> The above link helped me in some of the issues but still i am not able to
> find the replacement for class files like,
> 
> org.apache.log4j.helpers.LogLog
> org.apache.log4j.helpers.FileWatchdog
> 
> and few more.
> 
> I would like to know if there is any mapping documentation available for
> 1.x classes to 2.x classes? Please do the needful.
> 
> Thanks,
> Praveen Kumar



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

Re: log4j reduction of repeated message

[Remko Popma]

I believe this is possible, but it’s not trivial. See the discussion here: 
https://issues.apache.org/jira/browse/LOG4J2-1630

(Shameless plug) Every java main() method deserves http://picocli.info

> On Dec 14, 2017, at 2:18, Carlos Terron Bueno  wrote:
> 
> rsyslog has an option, 
> $RepeatedMsgReduction
>  tha can be used to reduce the number of log messages in a system. This 
> option groups the same messages, printing the message in the record and then 
> a line with the number of times it has been repeated.
> 
> Is it possible to do the same thing with log4j?
> 
> Thanks
> 
> Carlos

Re: Log4j Stacktrace - Only have certain lines in stacktrace

[Ralph Goers]

If you look at the documentation for the %ex pattern of the PatternLayout [1] 
you will see that you can do the exact opposite. You can specify packages that 
you don’t want to see. 

Ralph

[1] http://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout 


> On Dec 11, 2017, at 12:01 PM, Mikael Ståldal  wrote:
> 
> On 2017-12-02 16:01, Debraj Manna wrote:
>> In my stacktrace I only want to have lines starting with let's say com.xyz.
>> Is it possible to have something like the solution discussed in this answer
>>  ?
> 
> As far as I know, it is currently not possible to do this with Log4j.
> 
> Feel free to submit a feature request on JIRA: 
> https://issues.apache.org/jira/projects/LOG4J2
> 
> And maybe provide a patch or GitHub PR to implement it: 
> https://github.com/apache/logging-log4j2/pulls
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 

Re: Log4j Stacktrace - Only have certain lines in stacktrace

[Mikael Ståldal]

On 2017-12-02 16:01, Debraj Manna wrote:

In my stacktrace I only want to have lines starting with let's say com.xyz.
Is it possible to have something like the solution discussed in this answer
 ?


As far as I know, it is currently not possible to do this with Log4j.

Feel free to submit a feature request on JIRA: 
https://issues.apache.org/jira/projects/LOG4J2


And maybe provide a patch or GitHub PR to implement it: 
https://github.com/apache/logging-log4j2/pulls





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

Re: log4j vs log4jextras v1.x

[Remko Popma]

Not sure, you’d have to try. 

But be aware that Log4j 1.2 has been End of Life for 2 years now and is known 
to be broken on Java 9. 

We recommend everyone to upgrade to Log4j2. Log4j2 has better performance and 
can be configured to be garbage free. Just switching to Log4j2 is likely to 
speed up your application. 

(Shameless plug) Every java main() method deserves http://picocli.info

> On Nov 18, 2017, at 5:02, Alex O'Ree  wrote:
> 
> Understood, but if I needed log4extras, would I just have just log4extras
> on the classpath or (log4jextras and log4j) on the classpath
> 
> 
>> On Nov 17, 2017 1:36 PM, "Ralph Goers"  wrote:
>> 
>> Log4jextras was extra stuff for Log4j 1. Log4j 1 is not longer supported
>> so neither would be log4jextras.
>> 
>> Ralph
>> 
>>> On Nov 17, 2017, at 11:22 AM, Alex O'Ree  wrote:
>>> 
>>> Sorry if this has been asked before, but i'm not clear on whether or not
>>> log4jextras is a replacement for log4j or an add on?
>>> 
>>> I've running into some issues where they are both in the classpath
>> causing
>>> a conflict between the Appender interface and am looking for solutions.
>>> Thanks!
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
>> 

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

Re: log4j vs log4jextras v1.x

[Alex O'Ree]

Understood, but if I needed log4extras, would I just have just log4extras
on the classpath or (log4jextras and log4j) on the classpath


On Nov 17, 2017 1:36 PM, "Ralph Goers"  wrote:

> Log4jextras was extra stuff for Log4j 1. Log4j 1 is not longer supported
> so neither would be log4jextras.
>
> Ralph
>
> > On Nov 17, 2017, at 11:22 AM, Alex O'Ree  wrote:
> >
> > Sorry if this has been asked before, but i'm not clear on whether or not
> > log4jextras is a replacement for log4j or an add on?
> >
> > I've running into some issues where they are both in the classpath
> causing
> > a conflict between the Appender interface and am looking for solutions.
> > Thanks!
>
>
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: log4j vs log4jextras v1.x

[Ralph Goers]

Log4jextras was extra stuff for Log4j 1. Log4j 1 is not longer supported so 
neither would be log4jextras.

Ralph

> On Nov 17, 2017, at 11:22 AM, Alex O'Ree  wrote:
> 
> Sorry if this has been asked before, but i'm not clear on whether or not
> log4jextras is a replacement for log4j or an add on?
> 
> I've running into some issues where they are both in the classpath causing
> a conflict between the Appender interface and am looking for solutions.
> Thanks!



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

Re: Log4j and Java 9 JPMS support

[Ralph Goers]

Actually, you are asking for a log file per module. That shouldn’t require a 
new ContextSelector. That would only be required if you wanted to have a 
separate configuration for each module.

Right now Log4j doesn’t do anything to identify what module a class is located 
in. That would be required to use the RoutingAppender. 

Log4j is not yet modularized. The module system was up in the air until about 6 
weeks ago so we put off work on that.

Ralph

> On Sep 18, 2017, at 7:57 AM, Matt Sicker  wrote:
> 
> Take a look at the ClassLoaderContextSelector class along with the JPMS
> API. It should be relatively self explanatory. Feel free to follow up with
> questions on the dev list if you want as well.
> 
> On 18 September 2017 at 09:40, Alex Sviridov 
> wrote:
> 
>> The problem is that I know nothing about log4j architecture. I am just a
>> user.
>> 
>> Is it so difficult task? If log4j has access to class it can access and
>> its module and after that use sift appender by module name.
>> Application module has name, automatic module has name,
>> all unnamed module goes to one file.
>> 
>> Another question - has anyone tried log4j as named module on java 9?
>> 
>> Best regards, Alex
>> 
>> 
>>> Понедельник, 18 сентября 2017, 16:44 +03:00 от Ralph Goers <
>> ralph.go...@dslextreme.com>:
>>> 
>>> Right now LoggerContexts are organized around ClassLoaders. We haven’t
>> even talked about creating a ModuleContextSelector. If you want to help
>> contribute towards that it would be welcome.
>>> 
>>> Ralph
>>> 
 On Sep 18, 2017, at 1:18 AM, Alex Sviridov < ooo_satu...@mail.ru.INVALID
>>> wrote:
 
 Hi all
 
 Could anyone say if log4j 1/2 can create separate log file for every
>> JPMS module?
 
 For example I have application that consists of three named modules
>> moduleA, moduleB,
 moduleC. And I want to have three log files moduleA.log, moduleB.log,
>> moduleC.log.
 
 If such feature is not supported, can anyone say when approximately it
>> will be
 implemented.
 
 Best regards, Alex
>>> 
>>> 
>> 
>> 
>> --
>> Alex Sviridov
>> 
> 
> 
> 
> -- 
> Matt Sicker 



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

Re: Log4j and Java 9 JPMS support

[Ralph Goers]

Right now LoggerContexts are organized around ClassLoaders. We haven’t even 
talked about creating a ModuleContextSelector. If you want to help contribute 
towards that it would be welcome.

Ralph

> On Sep 18, 2017, at 1:18 AM, Alex Sviridov  
> wrote:
> 
> Hi all
> 
> Could anyone say if log4j 1/2 can create separate log file for every JPMS 
> module?
> 
> For example I have application that consists of three named modules moduleA, 
> moduleB,
> moduleC. And I want to have three log files moduleA.log, moduleB.log, 
> moduleC.log.
> 
> If such feature is not supported, can anyone say when approximately it will be
> implemented.
> 
> Best regards, Alex



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

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Remko Popma]

Details are here:
https://blogs.apache.org/logging/entry/moving_on_to_log4j_2

Sent from my iPhone

> On 1 Dec 2016, at 10:32, Christopher Schultz  
> wrote:
> 
> Remko,
> 
>> On 11/30/16 5:26 PM, Remko Popma wrote:
>> Chris,
>> 
>> Glad to hear that. 
>> 
>> Be aware that Log4j 1 is broken in Java 9 so you will need to go to
>> Log4j 2 when you upgrade Java.
> 
> I'm curious... in what way is log4j 1.x broken in Java 9?
> 
> I've been meaning to switch to log4j 2.x for a number of years, but
> since it ain't broke :)  ... until now, I guess.
> 
> Thanks,
> -chris
> 
>>> On 1 Dec 2016, at 1:41, Christopher Schultz  
>>> wrote:
>>> 
>>> All,
>>> 
>>> On 11/17/16 10:28 AM, Christopher Schultz wrote:
> So, I implemented an event trigger class in my driver class like this:
> 
> package com.my;
> public class Driver
> {
>   [...]
>   public static class NeverTriggeringEventEvaluator
>   implements TriggeringEventEvaluator
>   {
>   @Override
>   public boolean isTriggeringEvent(LoggingEvent arg0) {
>   return false;
>   }
>   }
> }
> 
> I enabled it in my configuration file like this:
> 
> log4j.appender.CLIENT.evaluatorClass=com.my.Driver$NeverTriggeringEventEvaluator
>>> 
>>> When using this NeverTriggeringEventEvaluator, I'm getting the behavior
>>> I want: all of my error messages are being sent in a single email message.
>>> 
>>> Thanks to all involved.
>>> 
>>> I may update it to be sensitive to the number of logging events so that
>>> it never actually loses events. Right now, I believe if I hit 501
>>> events, I'll lose one in the message that is sent when the appender is
>>> shut-down.
>>> 
>>> -chris
>>> 
>> 
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>> 
> 

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Christopher Schultz]

Remko,

On 11/30/16 5:26 PM, Remko Popma wrote:
> Chris,
> 
> Glad to hear that. 
> 
> Be aware that Log4j 1 is broken in Java 9 so you will need to go to
> Log4j 2 when you upgrade Java.

I'm curious... in what way is log4j 1.x broken in Java 9?

I've been meaning to switch to log4j 2.x for a number of years, but
since it ain't broke :)  ... until now, I guess.

Thanks,
-chris

>> On 1 Dec 2016, at 1:41, Christopher Schultz  
>> wrote:
>>
>> All,
>>
>> On 11/17/16 10:28 AM, Christopher Schultz wrote:
 So, I implemented an event trigger class in my driver class like this:

 package com.my;
 public class Driver
 {
[...]
public static class NeverTriggeringEventEvaluator
implements TriggeringEventEvaluator
{
@Override
public boolean isTriggeringEvent(LoggingEvent arg0) {
return false;
}
}
 }

 I enabled it in my configuration file like this:

 log4j.appender.CLIENT.evaluatorClass=com.my.Driver$NeverTriggeringEventEvaluator
>>
>> When using this NeverTriggeringEventEvaluator, I'm getting the behavior
>> I want: all of my error messages are being sent in a single email message.
>>
>> Thanks to all involved.
>>
>> I may update it to be sensitive to the number of logging events so that
>> it never actually loses events. Right now, I believe if I hit 501
>> events, I'll lose one in the message that is sent when the appender is
>> shut-down.
>>
>> -chris
>>
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 



signature.asc
Description: OpenPGP digital signature

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Remko Popma]

Chris,

Glad to hear that. 

Be aware that Log4j 1 is broken in Java 9 so you will need to go to Log4j 2 
when you upgrade Java. 

Remko

Sent from my iPhone

> On 1 Dec 2016, at 1:41, Christopher Schultz  
> wrote:
> 
> All,
> 
> On 11/17/16 10:28 AM, Christopher Schultz wrote:
>>> So, I implemented an event trigger class in my driver class like this:
>>> 
>>> package com.my;
>>> public class Driver
>>> {
>>>[...]
>>>public static class NeverTriggeringEventEvaluator
>>>implements TriggeringEventEvaluator
>>>{
>>>@Override
>>>public boolean isTriggeringEvent(LoggingEvent arg0) {
>>>return false;
>>>}
>>>}
>>> }
>>> 
>>> I enabled it in my configuration file like this:
>>> 
>>> log4j.appender.CLIENT.evaluatorClass=com.my.Driver$NeverTriggeringEventEvaluator
> 
> When using this NeverTriggeringEventEvaluator, I'm getting the behavior
> I want: all of my error messages are being sent in a single email message.
> 
> Thanks to all involved.
> 
> I may update it to be sensitive to the number of logging events so that
> it never actually loses events. Right now, I believe if I hit 501
> events, I'll lose one in the message that is sent when the appender is
> shut-down.
> 
> -chris
> 

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

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Christopher Schultz]

All,

On 11/17/16 10:28 AM, Christopher Schultz wrote:
>> So, I implemented an event trigger class in my driver class like this:
>>
>> package com.my;
>> public class Driver
>> {
>> [...]
>> public static class NeverTriggeringEventEvaluator
>> implements TriggeringEventEvaluator
>> {
>> @Override
>> public boolean isTriggeringEvent(LoggingEvent arg0) {
>> return false;
>> }
>> }
>> }
>>
>> I enabled it in my configuration file like this:
>>
>> log4j.appender.CLIENT.evaluatorClass=com.my.Driver$NeverTriggeringEventEvaluator

When using this NeverTriggeringEventEvaluator, I'm getting the behavior
I want: all of my error messages are being sent in a single email message.

Thanks to all involved.

I may update it to be sensitive to the number of logging events so that
it never actually loses events. Right now, I believe if I hit 501
events, I'll lose one in the message that is sent when the appender is
shut-down.

-chris



signature.asc
Description: OpenPGP digital signature

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Christopher Schultz]

All,

On 11/17/16 10:20 AM, Christopher Schultz wrote:
> All,
> 
> On 11/16/16 5:33 PM, Christopher Schultz wrote:
>> Scott,
>>
>> On 11/16/16 2:09 PM, Scott Harrington wrote:
> On 11/16/16 9:49 AM, Ralph Goers wrote:
>> First, I have to say that Log4j 1 reached end-of-life over a year
>> ago. We recommend you upgrade to Log4j 2.
>
> Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
> the same issue, though.

 I don’t know how to configure a TriggeringEventEvaluator in Log4j 1
 but I’d bet google does ;-)
>>>
>>> Chris: I have a ThrottledSMTPApppender subclass that I used for years
>>> under Log4j 1.x, it's very small but was somewhat tricky; it starts a
>>> "flusher" thread and attaches a shutdown hook to drain before exit.
>>> There is a TriggeringEventEvaluator that always returns false. There is
>>> a configureable "initialDelay" (default 10 seconds) and
>>> "messageInterval" (default 60 seconds).
>>
>> That sounds cool, but maybe overkill if I can get the
>> TriggeringEventEvaluator working with the stock log4j distro.
>>
>> (It looks like I'll need to write my own NeverTriggerEventEvaluator to
>> do that. It looks trivial so I'll try that first.)
> 
> So, I implemented an event trigger class in my driver class like this:
> 
> package com.my;
> public class Driver
> {
> [...]
> public static class NeverTriggeringEventEvaluator
> implements TriggeringEventEvaluator
> {
> @Override
> public boolean isTriggeringEvent(LoggingEvent arg0) {
> return false;
> }
> }
> }
> 
> I enabled it in my configuration file like this:
> 
> log4j.appender.CLIENT.evaluatorClass=com.my.Driver.NeverTriggeringEventEvaluator
> 
> When log4j initializes itself it emits this error on stdout:
> 
> log4j:ERROR Could not instantiate class
> [com.my.Driver.NeverTriggeringEventEvaluator].
> java.lang.ClassNotFoundException:
> com.chadis.unity.CHADISProUnityBridge.NeverTriggeringEventEvaluator
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> [...]
> 
> I'm not using any special ClassLoader acrobatics or anything like that.
> I copy/pasted the name of the fully-qualified class name from Eclipse so
> it's not a typo.
> 
> If I run "javap" with that class name and the effective CLASSPATH of the
> process when it runs, I get this output:
> 
> $ javap -classpath build/classes com.my.Driver.NeverTriggeringEventEvaluator
> 
> Compiled from "Driver.java"
> public class com.my.Driver$NeverTriggeringEventEvaluator implements
> org.apache.log4j.spi.TriggeringEventEvaluator {
>   public com.my.Driver$NeverTriggeringEventEvaluator();
>   public boolean isTriggeringEvent(org.apache.log4j.spi.LoggingEvent);
> }
> 
> Any ideas?
> 
> Do I need to use com.my.Driver$NeverTriggeringEventEvaluator instead?
> (Obviously, I'm trying that without waiting for an answer.)

That was it: the NeverTriggeringEventEvaluator is working as expected
when using the '$' embedded in the class name.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Christopher Schultz]

All,

On 11/16/16 5:33 PM, Christopher Schultz wrote:
> Scott,
> 
> On 11/16/16 2:09 PM, Scott Harrington wrote:
 On 11/16/16 9:49 AM, Ralph Goers wrote:
> First, I have to say that Log4j 1 reached end-of-life over a year
> ago. We recommend you upgrade to Log4j 2.

 Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
 the same issue, though.
>>>
>>> I don’t know how to configure a TriggeringEventEvaluator in Log4j 1
>>> but I’d bet google does ;-)
>>
>> Chris: I have a ThrottledSMTPApppender subclass that I used for years
>> under Log4j 1.x, it's very small but was somewhat tricky; it starts a
>> "flusher" thread and attaches a shutdown hook to drain before exit.
>> There is a TriggeringEventEvaluator that always returns false. There is
>> a configureable "initialDelay" (default 10 seconds) and
>> "messageInterval" (default 60 seconds).
> 
> That sounds cool, but maybe overkill if I can get the
> TriggeringEventEvaluator working with the stock log4j distro.
> 
> (It looks like I'll need to write my own NeverTriggerEventEvaluator to
> do that. It looks trivial so I'll try that first.)

So, I implemented an event trigger class in my driver class like this:

package com.my;
public class Driver
{
[...]
public static class NeverTriggeringEventEvaluator
implements TriggeringEventEvaluator
{
@Override
public boolean isTriggeringEvent(LoggingEvent arg0) {
return false;
}
}
}

I enabled it in my configuration file like this:

log4j.appender.CLIENT.evaluatorClass=com.my.Driver.NeverTriggeringEventEvaluator

When log4j initializes itself it emits this error on stdout:

log4j:ERROR Could not instantiate class
[com.my.Driver.NeverTriggeringEventEvaluator].
java.lang.ClassNotFoundException:
com.chadis.unity.CHADISProUnityBridge.NeverTriggeringEventEvaluator
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
[...]

I'm not using any special ClassLoader acrobatics or anything like that.
I copy/pasted the name of the fully-qualified class name from Eclipse so
it's not a typo.

If I run "javap" with that class name and the effective CLASSPATH of the
process when it runs, I get this output:

$ javap -classpath build/classes com.my.Driver.NeverTriggeringEventEvaluator

Compiled from "Driver.java"
public class com.my.Driver$NeverTriggeringEventEvaluator implements
org.apache.log4j.spi.TriggeringEventEvaluator {
  public com.my.Driver$NeverTriggeringEventEvaluator();
  public boolean isTriggeringEvent(org.apache.log4j.spi.LoggingEvent);
}

Any ideas?

Do I need to use com.my.Driver$NeverTriggeringEventEvaluator instead?
(Obviously, I'm trying that without waiting for an answer.)

-chris



signature.asc
Description: OpenPGP digital signature

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Gary Gregory]

You might not even need to change the configuration if you use the
"org.apache.log4j.config" package in the "log4j-1.2-api" module , which is
not well documented, yet.

Gary

On Wed, Nov 16, 2016 at 3:36 PM, Remko Popma  wrote:

> Chris,
>
> Are you aware that there is a log4j-1.2-api adapter included in Log4j2
> that allows you to keep your application code unchanged (unless you rely on
> the innards of Log4j 1.2)?
>
> You only need to change the configuration (the manual has tons of
> examples).
>
> Just FYI.
> Remko
>
> Sent from my iPhone
>
> > On 17 Nov 2016, at 7:33, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> >
> > Scott,
> >
> > On 11/16/16 2:09 PM, Scott Harrington wrote:
> > On 11/16/16 9:49 AM, Ralph Goers wrote:
> > First, I have to say that Log4j 1 reached end-of-life over a year
> > ago. We recommend you upgrade to Log4j 2.
> 
>  Fair enough. I'm not quite there, yet. I suspect that log4j 2 will
> have
>  the same issue, though.
> >>>
> >>> I don’t know how to configure a TriggeringEventEvaluator in Log4j 1
> >>> but I’d bet google does ;-)
> >>
> >> Chris: I have a ThrottledSMTPApppender subclass that I used for years
> >> under Log4j 1.x, it's very small but was somewhat tricky; it starts a
> >> "flusher" thread and attaches a shutdown hook to drain before exit.
> >> There is a TriggeringEventEvaluator that always returns false. There is
> >> a configureable "initialDelay" (default 10 seconds) and
> >> "messageInterval" (default 60 seconds).
> >
> > That sounds cool, but maybe overkill if I can get the
> > TriggeringEventEvaluator working with the stock log4j distro.
> >
> > (It looks like I'll need to write my own NeverTriggerEventEvaluator to
> > do that. It looks trivial so I'll try that first.)
> >
> >> I've since moved up to Log4j 2, and you are correct that Log4j 2 didn't
> >> do throttling/batching quite like I wanted, so I have a "ThrottledSMTP"
> >> Plugin for Log4j 2.
> >
> > :)
> >
> >> There was some discussion of this at LOG4J2-252, which is still open.
> >> I'll attach my two variants to that ticket with the hope they may be
> >> useful as-is to you or to others. However I don't have the time in
> >> foreseeable future to prepare the proper unit test and documentation
> >> that would be required to make it part of official Log4j2.
> >
> > Understood. If I (a) go down the ThrottledSMTPAppender route and (b)
> > move to log4j 2, I may finish-off that work. It's a long-shot, though.
> >
> > I really appreciate the feedback, though.
> >
> > -chris
> >
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Remko Popma]

Chris,

Are you aware that there is a log4j-1.2-api adapter included in Log4j2 that 
allows you to keep your application code unchanged (unless you rely on the 
innards of Log4j 1.2)?

You only need to change the configuration (the manual has tons of examples). 

Just FYI. 
Remko

Sent from my iPhone

> On 17 Nov 2016, at 7:33, Christopher Schultz  
> wrote:
> 
> Scott,
> 
> On 11/16/16 2:09 PM, Scott Harrington wrote:
> On 11/16/16 9:49 AM, Ralph Goers wrote:
> First, I have to say that Log4j 1 reached end-of-life over a year
> ago. We recommend you upgrade to Log4j 2.
 
 Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
 the same issue, though.
>>> 
>>> I don’t know how to configure a TriggeringEventEvaluator in Log4j 1
>>> but I’d bet google does ;-)
>> 
>> Chris: I have a ThrottledSMTPApppender subclass that I used for years
>> under Log4j 1.x, it's very small but was somewhat tricky; it starts a
>> "flusher" thread and attaches a shutdown hook to drain before exit.
>> There is a TriggeringEventEvaluator that always returns false. There is
>> a configureable "initialDelay" (default 10 seconds) and
>> "messageInterval" (default 60 seconds).
> 
> That sounds cool, but maybe overkill if I can get the
> TriggeringEventEvaluator working with the stock log4j distro.
> 
> (It looks like I'll need to write my own NeverTriggerEventEvaluator to
> do that. It looks trivial so I'll try that first.)
> 
>> I've since moved up to Log4j 2, and you are correct that Log4j 2 didn't
>> do throttling/batching quite like I wanted, so I have a "ThrottledSMTP"
>> Plugin for Log4j 2.
> 
> :)
> 
>> There was some discussion of this at LOG4J2-252, which is still open.
>> I'll attach my two variants to that ticket with the hope they may be
>> useful as-is to you or to others. However I don't have the time in
>> foreseeable future to prepare the proper unit test and documentation
>> that would be required to make it part of official Log4j2.
> 
> Understood. If I (a) go down the ThrottledSMTPAppender route and (b)
> move to log4j 2, I may finish-off that work. It's a long-shot, though.
> 
> I really appreciate the feedback, though.
> 
> -chris
> 

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

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Gary Gregory]

If you do look at Log4j2 it would be great if you could give us feedback on
what is missing for your use case. I or others can help turn things around
quickly to make Log4j 2 even better.

Gary

On Nov 16, 2016 2:33 PM, "Christopher Schultz" 
wrote:

> Scott,
>
> On 11/16/16 2:09 PM, Scott Harrington wrote:
> >>> On 11/16/16 9:49 AM, Ralph Goers wrote:
>  First, I have to say that Log4j 1 reached end-of-life over a year
>  ago. We recommend you upgrade to Log4j 2.
> >>>
> >>> Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
> >>> the same issue, though.
> >>
> >> I don’t know how to configure a TriggeringEventEvaluator in Log4j 1
> >> but I’d bet google does ;-)
> >
> > Chris: I have a ThrottledSMTPApppender subclass that I used for years
> > under Log4j 1.x, it's very small but was somewhat tricky; it starts a
> > "flusher" thread and attaches a shutdown hook to drain before exit.
> > There is a TriggeringEventEvaluator that always returns false. There is
> > a configureable "initialDelay" (default 10 seconds) and
> > "messageInterval" (default 60 seconds).
>
> That sounds cool, but maybe overkill if I can get the
> TriggeringEventEvaluator working with the stock log4j distro.
>
> (It looks like I'll need to write my own NeverTriggerEventEvaluator to
> do that. It looks trivial so I'll try that first.)
>
> > I've since moved up to Log4j 2, and you are correct that Log4j 2 didn't
> > do throttling/batching quite like I wanted, so I have a "ThrottledSMTP"
> > Plugin for Log4j 2.
>
> :)
>
> > There was some discussion of this at LOG4J2-252, which is still open.
> > I'll attach my two variants to that ticket with the hope they may be
> > useful as-is to you or to others. However I don't have the time in
> > foreseeable future to prepare the proper unit test and documentation
> > that would be required to make it part of official Log4j2.
>
> Understood. If I (a) go down the ThrottledSMTPAppender route and (b)
> move to log4j 2, I may finish-off that work. It's a long-shot, though.
>
> I really appreciate the feedback, though.
>
> -chris
>
>

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Christopher Schultz]

Scott,

On 11/16/16 2:09 PM, Scott Harrington wrote:
>>> On 11/16/16 9:49 AM, Ralph Goers wrote:
 First, I have to say that Log4j 1 reached end-of-life over a year
 ago. We recommend you upgrade to Log4j 2.
>>>
>>> Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
>>> the same issue, though.
>>
>> I don’t know how to configure a TriggeringEventEvaluator in Log4j 1
>> but I’d bet google does ;-)
> 
> Chris: I have a ThrottledSMTPApppender subclass that I used for years
> under Log4j 1.x, it's very small but was somewhat tricky; it starts a
> "flusher" thread and attaches a shutdown hook to drain before exit.
> There is a TriggeringEventEvaluator that always returns false. There is
> a configureable "initialDelay" (default 10 seconds) and
> "messageInterval" (default 60 seconds).

That sounds cool, but maybe overkill if I can get the
TriggeringEventEvaluator working with the stock log4j distro.

(It looks like I'll need to write my own NeverTriggerEventEvaluator to
do that. It looks trivial so I'll try that first.)

> I've since moved up to Log4j 2, and you are correct that Log4j 2 didn't
> do throttling/batching quite like I wanted, so I have a "ThrottledSMTP"
> Plugin for Log4j 2.

:)

> There was some discussion of this at LOG4J2-252, which is still open.
> I'll attach my two variants to that ticket with the hope they may be
> useful as-is to you or to others. However I don't have the time in
> foreseeable future to prepare the proper unit test and documentation
> that would be required to make it part of official Log4j2.

Understood. If I (a) go down the ThrottledSMTPAppender route and (b)
move to log4j 2, I may finish-off that work. It's a long-shot, though.

I really appreciate the feedback, though.

-chris



signature.asc
Description: OpenPGP digital signature

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Scott Harrington]

On 11/16/16 9:49 AM, Ralph Goers wrote:

First, I have to say that Log4j 1 reached end-of-life over a year
ago. We recommend you upgrade to Log4j 2.


Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
the same issue, though.


I don’t know how to configure a TriggeringEventEvaluator in Log4j 1 but I’d bet 
google does ;-)


Chris: I have a ThrottledSMTPApppender subclass that I used for years 
under Log4j 1.x, it's very small but was somewhat tricky; it starts a 
"flusher" thread and attaches a shutdown hook to drain before exit. There 
is a TriggeringEventEvaluator that always returns false. There is a 
configureable "initialDelay" (default 10 seconds) and "messageInterval" 
(default 60 seconds).


I've since moved up to Log4j 2, and you are correct that Log4j 2 didn't do 
throttling/batching quite like I wanted, so I have a "ThrottledSMTP" 
Plugin for Log4j 2.


There was some discussion of this at LOG4J2-252, which is still open. I'll 
attach my two variants to that ticket with the hope they may be useful 
as-is to you or to others. However I don't have the time in foreseeable 
future to prepare the proper unit test and documentation that would be 
required to make it part of official Log4j2.

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

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Ralph Goers]

> On Nov 16, 2016, at 10:11 AM, Christopher Schultz 
>  wrote:
> 
> Ralph,
> 
> On 11/16/16 9:49 AM, Ralph Goers wrote:
>> First, I have to say that Log4j 1 reached end-of-life over a year
>> ago. We recommend you upgrade to Log4j 2.
> 
> Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
> the same issue, though.
> 
>> I don’t know what you mean by “each log message seems to generate its
>> own separate email message”. The SMTP appender accumulates log events
>> in a buffer until a triggering event occurs (usually an error event)
>> and then all the buffered events are sent in an email.
> 
> This is not what I'm seeing. I'm seeing e.g. 10 ERROR messages logged in
> the span of about a minute to the main log file (e.g. my-process.log on
> the disk) and then 10 separate email messages with one log line per
> message in them.

If your application isn’t logging any other events (info, debug, etc) in 
between the errors then this behavior is correct. It would also be correct if 
you have filtering set up so that the log events never reach the SMTP appender 
as it can only place the events in its buffer that reach it. So if your loggers 
are set to error you could only see the error events in the emails and each 
would be sent separately as each is a triggering event. And yes, a call to 
logger.error() generates an error event while logger.debug would generate a 
debug event.

I don’t know how to configure a TriggeringEventEvaluator in Log4j 1 but I’d bet 
google does ;-)

Ralph


> 
> I have an example from 09:25 US-Eastern this morning: I got 7 separate
> email messages. The first message has this content (timestamps are UTC):
> 
> 2016-11-16 14:25:52,893 [main] ERROR [...logger and message content...]
> 
> The last one has this content:
> 
> 2016-11-16 14:27:13,569 [main] ERROR [...logger and message content...]
> 
> So in the space of about 90 seconds, log4j sent 7 separate email
> messages, and each email message contained a single log line.
> 
> I happen to be using log4j 1.2.17 which was the final release of log4j 1.x.
> 
> When you say "an error event" will trigger an email to be sent... do you
> mean a log.error() call? If so, perhaps the problem is that my threshold
> has been set to ERROR so I'm only reacting to ERROR events. If I were
> logging at the TRACE level, would I get a whole bunch of TRACE and a
> single ERROR in each email message?
> 
> Looking at the javadoc, it seems like that might be the case:
> 
> "
> The default constructor will instantiate the appender with a
> TriggeringEventEvaluator that will trigger on events with level ERROR or
> higher.
> "
> 
> I'm using a .properties file to configure log4j. How can I configure a
> TriggeringEventEvaluator to, saw, only trigger on e.g. FATAL log events?
> 
>> This happens each time a triggering event occurs. I see the logic for
>> sendOnClose and expect what you are doing should work, but I haven’t
>> worked with the Log4j 1 code in years so I can’t say for sure.
> 
> Thanks,
> -chris
> 



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

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Gary Gregory]

You might have to use an XML configuration file to get that to work in
Log4j 1: See org.apache.log4j.net.SMTPAppenderTest.testTrigger()

Gary

On Wed, Nov 16, 2016 at 9:11 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Ralph,
>
> On 11/16/16 9:49 AM, Ralph Goers wrote:
> > First, I have to say that Log4j 1 reached end-of-life over a year
> > ago. We recommend you upgrade to Log4j 2.
>
> Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
> the same issue, though.
>
> > I don’t know what you mean by “each log message seems to generate its
> > own separate email message”. The SMTP appender accumulates log events
> > in a buffer until a triggering event occurs (usually an error event)
> > and then all the buffered events are sent in an email.
>
> This is not what I'm seeing. I'm seeing e.g. 10 ERROR messages logged in
> the span of about a minute to the main log file (e.g. my-process.log on
> the disk) and then 10 separate email messages with one log line per
> message in them.
>
> I have an example from 09:25 US-Eastern this morning: I got 7 separate
> email messages. The first message has this content (timestamps are UTC):
>
> 2016-11-16 14:25:52,893 [main] ERROR [...logger and message content...]
>
> The last one has this content:
>
> 2016-11-16 14:27:13,569 [main] ERROR [...logger and message content...]
>
> So in the space of about 90 seconds, log4j sent 7 separate email
> messages, and each email message contained a single log line.
>
> I happen to be using log4j 1.2.17 which was the final release of log4j 1.x.
>
> When you say "an error event" will trigger an email to be sent... do you
> mean a log.error() call? If so, perhaps the problem is that my threshold
> has been set to ERROR so I'm only reacting to ERROR events. If I were
> logging at the TRACE level, would I get a whole bunch of TRACE and a
> single ERROR in each email message?
>
> Looking at the javadoc, it seems like that might be the case:
>
> "
> The default constructor will instantiate the appender with a
> TriggeringEventEvaluator that will trigger on events with level ERROR or
> higher.
> "
>
> I'm using a .properties file to configure log4j. How can I configure a
> TriggeringEventEvaluator to, saw, only trigger on e.g. FATAL log events?
>
> > This happens each time a triggering event occurs. I see the logic for
> > sendOnClose and expect what you are doing should work, but I haven’t
> > worked with the Log4j 1 code in years so I can’t say for sure.
>
> Thanks,
> -chris
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Christopher Schultz]

Ralph,

On 11/16/16 9:49 AM, Ralph Goers wrote:
> First, I have to say that Log4j 1 reached end-of-life over a year
> ago. We recommend you upgrade to Log4j 2.

Fair enough. I'm not quite there, yet. I suspect that log4j 2 will have
the same issue, though.

> I don’t know what you mean by “each log message seems to generate its
> own separate email message”. The SMTP appender accumulates log events
> in a buffer until a triggering event occurs (usually an error event)
> and then all the buffered events are sent in an email.

This is not what I'm seeing. I'm seeing e.g. 10 ERROR messages logged in
the span of about a minute to the main log file (e.g. my-process.log on
the disk) and then 10 separate email messages with one log line per
message in them.

I have an example from 09:25 US-Eastern this morning: I got 7 separate
email messages. The first message has this content (timestamps are UTC):

2016-11-16 14:25:52,893 [main] ERROR [...logger and message content...]

The last one has this content:

2016-11-16 14:27:13,569 [main] ERROR [...logger and message content...]

So in the space of about 90 seconds, log4j sent 7 separate email
messages, and each email message contained a single log line.

I happen to be using log4j 1.2.17 which was the final release of log4j 1.x.

When you say "an error event" will trigger an email to be sent... do you
mean a log.error() call? If so, perhaps the problem is that my threshold
has been set to ERROR so I'm only reacting to ERROR events. If I were
logging at the TRACE level, would I get a whole bunch of TRACE and a
single ERROR in each email message?

Looking at the javadoc, it seems like that might be the case:

"
The default constructor will instantiate the appender with a
TriggeringEventEvaluator that will trigger on events with level ERROR or
higher.
"

I'm using a .properties file to configure log4j. How can I configure a
TriggeringEventEvaluator to, saw, only trigger on e.g. FATAL log events?

> This happens each time a triggering event occurs. I see the logic for
> sendOnClose and expect what you are doing should work, but I haven’t
> worked with the Log4j 1 code in years so I can’t say for sure.

Thanks,
-chris



signature.asc
Description: OpenPGP digital signature

Re: [log4j 1.x] Batch-sending with SMTPAppender

[Ralph Goers]

First, I have to say that Log4j 1 reached end-of-life over a year ago. We 
recommend you upgrade to Log4j 2.

I don’t know what you mean by “each log message seems to generate its own 
separate email message”. The SMTP appender accumulates log events in a buffer 
until a triggering event occurs (usually an error event) and then all the 
buffered events are sent in an email. This happens each time a triggering event 
occurs. I see the logic for sendOnClose and expect what you are doing should 
work, but I haven’t worked with the Log4j 1 code in years so I can’t say for 
sure.

Ralph

> On Nov 16, 2016, at 7:24 AM, Christopher Schultz 
>  wrote:
> 
> All,
> 
> Apologies if this has been posted before.. I checked the archives but
> it's hard to search for such terms... lots of stuff comes up.
> 
> I have an SMTPAppender configured and it's working (mostly) as expected.
> The only problem is that each log message seems to generate its own
> separate email message.
> 
> My use-case is a periodic job where I'd like to send any errors to an
> email box. Two configuration settings for the SMTPAppender led me to
> believe that the SMTPAppender might batch emails:
> 
> 1. BufferSize
> 2. SendOnClose
> 
> The javadoc specifically mentions that the BufferSize will affect the
> number of logging events delivered "in this email" which I assumed meant
> "each email message".
> 
> My relevant configuration:
> 
> log4j.appender.CLIENT.bufferSize=500
> log4j.appender.CLIENT.sendOnClose=true
> 
> Usually, we get something like 0 - 12 errors per run of this periodic
> job, so I wouldn't expect to get anywhere near the 500 limit. Ideally,
> all of those log messages would be batched together and sent when the
> logger shuts down. At the end of the program, I do one of these:
> 
>finally
>{
>org.apache.log4j.LogManager.shutdown();
>}
> 
> That ought to trigger the SendOnClose behavior and flush anything that
> hasn't already been sent.
> 
> Am I missing something in my configuration that is required to send
> these messages in batches? I'd prefer not to write the logs to a
> separate file and then use a secondary process to email that log file to
> the intended recipient.
> 
> Thanks,
> -chris
> 



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

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[DiFrango, Ronald]

Thanks…found it and switching over to it now.

Ron DiFrango







On 5/31/16, 4:44 PM, "Paul Benedict"  wrote:

>Refer to the Bill of Material section (BOM) here:
>https://logging.apache.org/log4j/2.x/maven-artifacts.html
>
>Cheers,
>Paul
>
>On Tue, May 31, 2016 at 3:41 PM, DiFrango, Ronald <
>ronald.difra...@capitalone.com> wrote:
>
>> Paul,
>>
>>
>> I hadn’t seen that before, that would be great!
>>
>> Ron DiFrango
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 5/31/16, 4:39 PM, "Paul Benedict"  wrote:
>>
>> >DiFrango, log4j includes a BOM you may want to consider using. This will
>> >keep all your log4j artifacts versioned the same.
>> >
>> >Cheers,
>> >Paul
>> >
>> >On Tue, May 31, 2016 at 3:37 PM, DiFrango, Ronald <
>> >ronald.difra...@capitalone.com> wrote:
>> >
>> >> Gary,
>> >>
>> >> It ended up being a transitive dependency conflict, one of the included
>> >> libraries had 2.5.
>> >>
>> >> Ron DiFrango
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 5/31/16, 3:38 PM, "DiFrango, Ronald" > >
>> >> wrote:
>> >>
>> >> >Gary,
>> >> >
>> >> >I did a full clean and install via Maven, but I’ll double check the
>> >> dependencies.
>> >> >
>> >> >Thanks,
>> >> >
>> >> >Ron
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >On 5/31/16, 3:35 PM, "Gary Gregory"  wrote:
>> >> >
>> >> >>On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
>> >> >>ronald.difra...@capitalone.com> wrote:
>> >> >>
>> >> >>> All,
>> >> >>>
>> >> >>> I just attempted to upgrade from log42j version 2.5 to 2.6 and I
>> >> started
>> >> >>> getting the following:
>> >> >>>
>> >> >>> java.lang.NoSuchMethodError:
>> >> >>>
>> >>
>> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
>> >> >>>
>> >> >>> This seems to happen on log messages where we do something simple
>> like:
>> >> >>>
>> >> >>> logger.debug(“Configuration Directory {}", configRoot);
>> >> >>>
>> >> >>> It does get resolved if I do something like:
>> >> >>>
>> >> >>> logger.debug(“Configuration Directory {}”, new
>> Object[]{configRoot});
>> >> >>>
>> >> >>> But that seems unnecessary.
>> >> >>>
>> >> >>> This worked perfectly fine in 2.5, any thing that I’m missing?
>> >> >>>
>> >> >>
>> >> >>And yet I see the Logger debug(String, Object) method here:
>> >> >>
>> >>
>> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)
>> >> >>
>> >> >>Can you check your classpath? There is something odd going on.
>> >> >>
>> >> >>What happens if you try to recompile your sources?
>> >> >>
>> >> >>Gary
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> Thanks,
>> >> >>>
>> >> >>> Ron
>> >> >>> 
>> >> >>>
>> >> >>> The information contained in this e-mail is confidential and/or
>> >> >>> proprietary to Capital One and/or its affiliates and may only be
>> used
>> >> >>> solely in performance of work or services for Capital One. The
>> >> information
>> >> >>> transmitted herewith is intended only for use by the individual or
>> >> entity
>> >> >>> to which it is addressed. If the reader of this message is not the
>> >> intended
>> >> >>> recipient, you are hereby notified that any review, retransmission,
>> >> >>> dissemination, distribution, copying or other use of, or taking of
>> any
>> >> >>> action in reliance upon this information is strictly prohibited. If
>> you
>> >> >>> have received this communication in error, please contact the sender
>> >> and
>> >> >>> delete the material from your computer.
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >>--
>> >> >>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >> >>Java Persistence with Hibernate, Second Edition
>> >> >>
>> >> >>JUnit in Action, Second Edition 
>> >> >>Spring Batch in Action 
>> >> >>Blog: http://garygregory.wordpress.com
>> >> >>Home: http://garygregory.com/
>> >> >>Tweet! http://twitter.com/GaryGregory
>> >> >
>> >> >
>> >> >The information contained in this e-mail is confidential and/or
>> >> proprietary to Capital One and/or its affiliates and may only be used
>> >> solely in performance of work or services for Capital One. The
>> information
>> >> transmitted herewith is intended only for use by the individual or
>> entity
>> >> to which it is addressed. If the reader of this message is not the
>> intended
>> >> recipient, you are hereby notified that any review, retransmission,
>> >> dissemination, distribution, copying or other use of, or taking of any
>> >> action in reliance upon this information is strictly prohibited. If you
>> >> have received this communication in error, please contact the sender and
>> >> delete the material from your computer.
>> >> 
>> >>
>> >> The information contained in this e-mail is confide

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[Paul Benedict]

Refer to the Bill of Material section (BOM) here:
https://logging.apache.org/log4j/2.x/maven-artifacts.html

Cheers,
Paul

On Tue, May 31, 2016 at 3:41 PM, DiFrango, Ronald <
ronald.difra...@capitalone.com> wrote:

> Paul,
>
>
> I hadn’t seen that before, that would be great!
>
> Ron DiFrango
>
>
>
>
>
>
>
>
>
>
> On 5/31/16, 4:39 PM, "Paul Benedict"  wrote:
>
> >DiFrango, log4j includes a BOM you may want to consider using. This will
> >keep all your log4j artifacts versioned the same.
> >
> >Cheers,
> >Paul
> >
> >On Tue, May 31, 2016 at 3:37 PM, DiFrango, Ronald <
> >ronald.difra...@capitalone.com> wrote:
> >
> >> Gary,
> >>
> >> It ended up being a transitive dependency conflict, one of the included
> >> libraries had 2.5.
> >>
> >> Ron DiFrango
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 5/31/16, 3:38 PM, "DiFrango, Ronald"  >
> >> wrote:
> >>
> >> >Gary,
> >> >
> >> >I did a full clean and install via Maven, but I’ll double check the
> >> dependencies.
> >> >
> >> >Thanks,
> >> >
> >> >Ron
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >On 5/31/16, 3:35 PM, "Gary Gregory"  wrote:
> >> >
> >> >>On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
> >> >>ronald.difra...@capitalone.com> wrote:
> >> >>
> >> >>> All,
> >> >>>
> >> >>> I just attempted to upgrade from log42j version 2.5 to 2.6 and I
> >> started
> >> >>> getting the following:
> >> >>>
> >> >>> java.lang.NoSuchMethodError:
> >> >>>
> >>
> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
> >> >>>
> >> >>> This seems to happen on log messages where we do something simple
> like:
> >> >>>
> >> >>> logger.debug(“Configuration Directory {}", configRoot);
> >> >>>
> >> >>> It does get resolved if I do something like:
> >> >>>
> >> >>> logger.debug(“Configuration Directory {}”, new
> Object[]{configRoot});
> >> >>>
> >> >>> But that seems unnecessary.
> >> >>>
> >> >>> This worked perfectly fine in 2.5, any thing that I’m missing?
> >> >>>
> >> >>
> >> >>And yet I see the Logger debug(String, Object) method here:
> >> >>
> >>
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)
> >> >>
> >> >>Can you check your classpath? There is something odd going on.
> >> >>
> >> >>What happens if you try to recompile your sources?
> >> >>
> >> >>Gary
> >> >>
> >> >>
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Ron
> >> >>> 
> >> >>>
> >> >>> The information contained in this e-mail is confidential and/or
> >> >>> proprietary to Capital One and/or its affiliates and may only be
> used
> >> >>> solely in performance of work or services for Capital One. The
> >> information
> >> >>> transmitted herewith is intended only for use by the individual or
> >> entity
> >> >>> to which it is addressed. If the reader of this message is not the
> >> intended
> >> >>> recipient, you are hereby notified that any review, retransmission,
> >> >>> dissemination, distribution, copying or other use of, or taking of
> any
> >> >>> action in reliance upon this information is strictly prohibited. If
> you
> >> >>> have received this communication in error, please contact the sender
> >> and
> >> >>> delete the material from your computer.
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >>--
> >> >>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >> >>Java Persistence with Hibernate, Second Edition
> >> >>
> >> >>JUnit in Action, Second Edition 
> >> >>Spring Batch in Action 
> >> >>Blog: http://garygregory.wordpress.com
> >> >>Home: http://garygregory.com/
> >> >>Tweet! http://twitter.com/GaryGregory
> >> >
> >> >
> >> >The information contained in this e-mail is confidential and/or
> >> proprietary to Capital One and/or its affiliates and may only be used
> >> solely in performance of work or services for Capital One. The
> information
> >> transmitted herewith is intended only for use by the individual or
> entity
> >> to which it is addressed. If the reader of this message is not the
> intended
> >> recipient, you are hereby notified that any review, retransmission,
> >> dissemination, distribution, copying or other use of, or taking of any
> >> action in reliance upon this information is strictly prohibited. If you
> >> have received this communication in error, please contact the sender and
> >> delete the material from your computer.
> >> 
> >>
> >> The information contained in this e-mail is confidential and/or
> >> proprietary to Capital One and/or its affiliates and may only be used
> >> solely in performance of work or services for Capital One. The
> information
> >> transmitted herewith is intended only for use by the individual or
> entity
> >> to which it is addressed. 

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[DiFrango, Ronald]

Paul,


I hadn’t seen that before, that would be great!

Ron DiFrango










On 5/31/16, 4:39 PM, "Paul Benedict"  wrote:

>DiFrango, log4j includes a BOM you may want to consider using. This will
>keep all your log4j artifacts versioned the same.
>
>Cheers,
>Paul
>
>On Tue, May 31, 2016 at 3:37 PM, DiFrango, Ronald <
>ronald.difra...@capitalone.com> wrote:
>
>> Gary,
>>
>> It ended up being a transitive dependency conflict, one of the included
>> libraries had 2.5.
>>
>> Ron DiFrango
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 5/31/16, 3:38 PM, "DiFrango, Ronald" 
>> wrote:
>>
>> >Gary,
>> >
>> >I did a full clean and install via Maven, but I’ll double check the
>> dependencies.
>> >
>> >Thanks,
>> >
>> >Ron
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >On 5/31/16, 3:35 PM, "Gary Gregory"  wrote:
>> >
>> >>On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
>> >>ronald.difra...@capitalone.com> wrote:
>> >>
>> >>> All,
>> >>>
>> >>> I just attempted to upgrade from log42j version 2.5 to 2.6 and I
>> started
>> >>> getting the following:
>> >>>
>> >>> java.lang.NoSuchMethodError:
>> >>>
>> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
>> >>>
>> >>> This seems to happen on log messages where we do something simple like:
>> >>>
>> >>> logger.debug(“Configuration Directory {}", configRoot);
>> >>>
>> >>> It does get resolved if I do something like:
>> >>>
>> >>> logger.debug(“Configuration Directory {}”, new Object[]{configRoot});
>> >>>
>> >>> But that seems unnecessary.
>> >>>
>> >>> This worked perfectly fine in 2.5, any thing that I’m missing?
>> >>>
>> >>
>> >>And yet I see the Logger debug(String, Object) method here:
>> >>
>> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)
>> >>
>> >>Can you check your classpath? There is something odd going on.
>> >>
>> >>What happens if you try to recompile your sources?
>> >>
>> >>Gary
>> >>
>> >>
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Ron
>> >>> 
>> >>>
>> >>> The information contained in this e-mail is confidential and/or
>> >>> proprietary to Capital One and/or its affiliates and may only be used
>> >>> solely in performance of work or services for Capital One. The
>> information
>> >>> transmitted herewith is intended only for use by the individual or
>> entity
>> >>> to which it is addressed. If the reader of this message is not the
>> intended
>> >>> recipient, you are hereby notified that any review, retransmission,
>> >>> dissemination, distribution, copying or other use of, or taking of any
>> >>> action in reliance upon this information is strictly prohibited. If you
>> >>> have received this communication in error, please contact the sender
>> and
>> >>> delete the material from your computer.
>> >>>
>> >>
>> >>
>> >>
>> >>--
>> >>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >>Java Persistence with Hibernate, Second Edition
>> >>
>> >>JUnit in Action, Second Edition 
>> >>Spring Batch in Action 
>> >>Blog: http://garygregory.wordpress.com
>> >>Home: http://garygregory.com/
>> >>Tweet! http://twitter.com/GaryGregory
>> >
>> >
>> >The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the intended
>> recipient, you are hereby notified that any review, retransmission,
>> dissemination, distribution, copying or other use of, or taking of any
>> action in reliance upon this information is strictly prohibited. If you
>> have received this communication in error, please contact the sender and
>> delete the material from your computer.
>> 
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the intended
>> recipient, you are hereby notified that any review, retransmission,
>> dissemination, distribution, copying or other use of, or taking of any
>> action in reliance upon this information is strictly prohibited. If you
>> have received this communication in error, please contact the sender and
>> delete the material from your computer.
>>
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[Paul Benedict]

DiFrango, log4j includes a BOM you may want to consider using. This will
keep all your log4j artifacts versioned the same.

Cheers,
Paul

On Tue, May 31, 2016 at 3:37 PM, DiFrango, Ronald <
ronald.difra...@capitalone.com> wrote:

> Gary,
>
> It ended up being a transitive dependency conflict, one of the included
> libraries had 2.5.
>
> Ron DiFrango
>
>
>
>
>
>
>
>
>
> On 5/31/16, 3:38 PM, "DiFrango, Ronald" 
> wrote:
>
> >Gary,
> >
> >I did a full clean and install via Maven, but I’ll double check the
> dependencies.
> >
> >Thanks,
> >
> >Ron
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >On 5/31/16, 3:35 PM, "Gary Gregory"  wrote:
> >
> >>On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
> >>ronald.difra...@capitalone.com> wrote:
> >>
> >>> All,
> >>>
> >>> I just attempted to upgrade from log42j version 2.5 to 2.6 and I
> started
> >>> getting the following:
> >>>
> >>> java.lang.NoSuchMethodError:
> >>>
> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
> >>>
> >>> This seems to happen on log messages where we do something simple like:
> >>>
> >>> logger.debug(“Configuration Directory {}", configRoot);
> >>>
> >>> It does get resolved if I do something like:
> >>>
> >>> logger.debug(“Configuration Directory {}”, new Object[]{configRoot});
> >>>
> >>> But that seems unnecessary.
> >>>
> >>> This worked perfectly fine in 2.5, any thing that I’m missing?
> >>>
> >>
> >>And yet I see the Logger debug(String, Object) method here:
> >>
> https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)
> >>
> >>Can you check your classpath? There is something odd going on.
> >>
> >>What happens if you try to recompile your sources?
> >>
> >>Gary
> >>
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Ron
> >>> 
> >>>
> >>> The information contained in this e-mail is confidential and/or
> >>> proprietary to Capital One and/or its affiliates and may only be used
> >>> solely in performance of work or services for Capital One. The
> information
> >>> transmitted herewith is intended only for use by the individual or
> entity
> >>> to which it is addressed. If the reader of this message is not the
> intended
> >>> recipient, you are hereby notified that any review, retransmission,
> >>> dissemination, distribution, copying or other use of, or taking of any
> >>> action in reliance upon this information is strictly prohibited. If you
> >>> have received this communication in error, please contact the sender
> and
> >>> delete the material from your computer.
> >>>
> >>
> >>
> >>
> >>--
> >>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >>Java Persistence with Hibernate, Second Edition
> >>
> >>JUnit in Action, Second Edition 
> >>Spring Batch in Action 
> >>Blog: http://garygregory.wordpress.com
> >>Home: http://garygregory.com/
> >>Tweet! http://twitter.com/GaryGregory
> >
> >
> >The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
> 
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[DiFrango, Ronald]

Gary,

It ended up being a transitive dependency conflict, one of the included 
libraries had 2.5.

Ron DiFrango









On 5/31/16, 3:38 PM, "DiFrango, Ronald"  wrote:

>Gary,
>
>I did a full clean and install via Maven, but I’ll double check the 
>dependencies.
>
>Thanks,
>
>Ron
>
>
>
>
>
>
>
>
>
>On 5/31/16, 3:35 PM, "Gary Gregory"  wrote:
>
>>On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
>>ronald.difra...@capitalone.com> wrote:
>>
>>> All,
>>>
>>> I just attempted to upgrade from log42j version 2.5 to 2.6 and I started
>>> getting the following:
>>>
>>> java.lang.NoSuchMethodError:
>>> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
>>>
>>> This seems to happen on log messages where we do something simple like:
>>>
>>> logger.debug(“Configuration Directory {}", configRoot);
>>>
>>> It does get resolved if I do something like:
>>>
>>> logger.debug(“Configuration Directory {}”, new Object[]{configRoot});
>>>
>>> But that seems unnecessary.
>>>
>>> This worked perfectly fine in 2.5, any thing that I’m missing?
>>>
>>
>>And yet I see the Logger debug(String, Object) method here:
>>https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)
>>
>>Can you check your classpath? There is something odd going on.
>>
>>What happens if you try to recompile your sources?
>>
>>Gary
>>
>>
>>>
>>> Thanks,
>>>
>>> Ron
>>> 
>>>
>>> The information contained in this e-mail is confidential and/or
>>> proprietary to Capital One and/or its affiliates and may only be used
>>> solely in performance of work or services for Capital One. The information
>>> transmitted herewith is intended only for use by the individual or entity
>>> to which it is addressed. If the reader of this message is not the intended
>>> recipient, you are hereby notified that any review, retransmission,
>>> dissemination, distribution, copying or other use of, or taking of any
>>> action in reliance upon this information is strictly prohibited. If you
>>> have received this communication in error, please contact the sender and
>>> delete the material from your computer.
>>>
>>
>>
>>
>>-- 
>>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>Java Persistence with Hibernate, Second Edition
>>
>>JUnit in Action, Second Edition 
>>Spring Batch in Action 
>>Blog: http://garygregory.wordpress.com
>>Home: http://garygregory.com/
>>Tweet! http://twitter.com/GaryGregory
>
>
>The information contained in this e-mail is confidential and/or proprietary to 
>Capital One and/or its affiliates and may only be used solely in performance 
>of work or services for Capital One. The information transmitted herewith is 
>intended only for use by the individual or entity to which it is addressed. If 
>the reader of this message is not the intended recipient, you are hereby 
>notified that any review, retransmission, dissemination, distribution, copying 
>or other use of, or taking of any action in reliance upon this information is 
>strictly prohibited. If you have received this communication in error, please 
>contact the sender and delete the material from your computer.


The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

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

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[DiFrango, Ronald]

Gary,

I did a full clean and install via Maven, but I’ll double check the 
dependencies.

Thanks,

Ron









On 5/31/16, 3:35 PM, "Gary Gregory"  wrote:

>On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
>ronald.difra...@capitalone.com> wrote:
>
>> All,
>>
>> I just attempted to upgrade from log42j version 2.5 to 2.6 and I started
>> getting the following:
>>
>> java.lang.NoSuchMethodError:
>> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
>>
>> This seems to happen on log messages where we do something simple like:
>>
>> logger.debug(“Configuration Directory {}", configRoot);
>>
>> It does get resolved if I do something like:
>>
>> logger.debug(“Configuration Directory {}”, new Object[]{configRoot});
>>
>> But that seems unnecessary.
>>
>> This worked perfectly fine in 2.5, any thing that I’m missing?
>>
>
>And yet I see the Logger debug(String, Object) method here:
>https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)
>
>Can you check your classpath? There is something odd going on.
>
>What happens if you try to recompile your sources?
>
>Gary
>
>
>>
>> Thanks,
>>
>> Ron
>> 
>>
>> The information contained in this e-mail is confidential and/or
>> proprietary to Capital One and/or its affiliates and may only be used
>> solely in performance of work or services for Capital One. The information
>> transmitted herewith is intended only for use by the individual or entity
>> to which it is addressed. If the reader of this message is not the intended
>> recipient, you are hereby notified that any review, retransmission,
>> dissemination, distribution, copying or other use of, or taking of any
>> action in reliance upon this information is strictly prohibited. If you
>> have received this communication in error, please contact the sender and
>> delete the material from your computer.
>>
>
>
>
>-- 
>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>Java Persistence with Hibernate, Second Edition
>
>JUnit in Action, Second Edition 
>Spring Batch in Action 
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory


The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.

Re: Log4J 2.5 -> 2.6 Upgrade NoSuchMethodError

[Gary Gregory]

On Tue, May 31, 2016 at 11:42 AM, DiFrango, Ronald <
ronald.difra...@capitalone.com> wrote:

> All,
>
> I just attempted to upgrade from log42j version 2.5 to 2.6 and I started
> getting the following:
>
> java.lang.NoSuchMethodError:
> org.apache.logging.log4j.Logger.debug(Ljava/lang/String;Ljava/lang/Object;)V
>
> This seems to happen on log messages where we do something simple like:
>
> logger.debug(“Configuration Directory {}", configRoot);
>
> It does get resolved if I do something like:
>
> logger.debug(“Configuration Directory {}”, new Object[]{configRoot});
>
> But that seems unnecessary.
>
> This worked perfectly fine in 2.5, any thing that I’m missing?
>

And yet I see the Logger debug(String, Object) method here:
https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Logger.html#debug(java.lang.String,%20java.lang.Object)

Can you check your classpath? There is something odd going on.

What happens if you try to recompile your sources?

Gary


>
> Thanks,
>
> Ron
> 
>
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Log4J 2 configuration: parameterizing appender via environment variable

[Ralph Goers]

I was actually thinking that we might create a lookup that parses the results 
from other lookups. I’m just not sure what the syntax would be.


Ralph

> On Feb 10, 2016, at 2:49 PM, Gary Gregory  wrote:
> 
> It sounds like a pretty generic feature though. And making life easier for
> log4j1 migratory users is a huge bonus IMO.
> 
> How about contributing this as a patch?
> 
> Gary
> On Feb 10, 2016 1:32 PM, "Ralph Goers"  wrote:
> 
>> Yes, they are discrete attributes in Log4j2. However, you should be able
>> to handle this using your own Lookup. For example you could do:
>> 
>> 
>>
>> 
>> 
>> Then implement ZooLookup to parse the zookeeper.root.logger environment
>> variable and return the values for rootLevel and rootAppender.
>> 
>> Ralph
>> 
>>> On Feb 10, 2016, at 2:20 PM, Chris Nauroth 
>> wrote:
>>> 
>>> Hello Log4J community,
>>> 
>>> I'm currently investigating possible migration from Log4J 1 to Log4J 2
>> for
>>> Apache ZooKeeper.  For full context, please see Apache JIRA issue
>>> ZOOKEEPER-2342 [1].  I'm struggling with how to preserve one particular
>>> capability that we have already given to administrators for controlling
>>> their logging settings.  I can't find a way to achieve the same thing in
>>> Log4J 2, and I'd like to get your advice.
>>> 
>>> The ZooKeeper launch scripts support controlling the root logger by
>>> setting an environment variable named ZOO_LOG4J_PROP.  The value gets
>>> passed to the launched process as a -Dzookeeper.root.logger argument [2]:
>>> 
>>>   nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE
>>> "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \
>>>   "-Dzookeeper.log.file=${ZOO_LOG_FILE}"
>>> "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
>>>   -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \
>>>   -cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT"
>>> 2>&1 < /dev/null &
>>> 
>>> We have a Log4J 1 log4j.properties file that includes a default value for
>>> zookeeper.root.logger in case it is unspecified at process launch, and
>>> then the variable gets substituted into the declaration of
>>> log4j.rootLogger [3]:
>>> 
>>> zookeeper.root.logger=INFO, CONSOLE
>>> ...
>>> log4j.rootLogger=${zookeeper.root.logger}
>>> 
>>> The net effect of this is that it gives the administrator the capability
>>> to parameterize the appender at process launch time without needing to
>>> edit the log4j.properties file.  For example, they could run
>>> "ZOO_LOG4J_PROP=DEBUG,ROLLINGFILE; bin/zkServer.sh start".
>>> 
>>> I have not been able to replicate this functionality in Log4J 2.  From
>>> what I can tell, Log4J 2 configuration is more structured, so there are
>>> specific individual settings for things like rootLogger.level and
>>> rootLogger.appenderRefs.  There isn't a centralized spot where I can
>>> substitute in "DEBUG,ROLLINGFILE" or similar as a single string to toggle
>>> the settings.  That means that we'd have to advise administrators to
>>> switch to a model of editing their log4j2.properties file to achieve this
>>> instead of controlling it with the environment variable.  That would be
>>> seen as a backwards-incompatible change from the administrator's
>>> perspective.  I suppose an alternative could be to preserve the current
>>> functionality by trying to implement our own logic to parse things like
>>> "DEBUG,ROLLINGFILE" and translate to what Log4J 2 expects, but given the
>>> amount of flexibility that was possible, I expect attempting to do this
>>> would be brittle.
>>> 
>>> Does anyone have other suggestions for how to implement this?  Is there a
>>> Log4J 2 configuration feature that I failed to find that would be helpful
>>> here?
>>> 
>>> Thank you!
>>> 
>>> --Chris Nauroth
>>> 
>>> [1] https://issues.apache.org/jira/browse/ZOOKEEPER-2342
>>> [2]
>>> 
>> https://github.com/apache/zookeeper/blob/release-3.5.1/bin/zkServer.sh#L148
>>> -L151
>>> [3]
>>> 
>> https://github.com/apache/zookeeper/blob/release-3.5.1/conf/log4j.propertie
>>> s#L20-L33
>>> 
>>> 
>>> -
>>> 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 2 configuration: parameterizing appender via environment variable

[Gary Gregory]

It sounds like a pretty generic feature though. And making life easier for
log4j1 migratory users is a huge bonus IMO.

How about contributing this as a patch?

Gary
On Feb 10, 2016 1:32 PM, "Ralph Goers"  wrote:

> Yes, they are discrete attributes in Log4j2. However, you should be able
> to handle this using your own Lookup. For example you could do:
>
> 
> 
> 
>
> Then implement ZooLookup to parse the zookeeper.root.logger environment
> variable and return the values for rootLevel and rootAppender.
>
> Ralph
>
> > On Feb 10, 2016, at 2:20 PM, Chris Nauroth 
> wrote:
> >
> > Hello Log4J community,
> >
> > I'm currently investigating possible migration from Log4J 1 to Log4J 2
> for
> > Apache ZooKeeper.  For full context, please see Apache JIRA issue
> > ZOOKEEPER-2342 [1].  I'm struggling with how to preserve one particular
> > capability that we have already given to administrators for controlling
> > their logging settings.  I can't find a way to achieve the same thing in
> > Log4J 2, and I'd like to get your advice.
> >
> > The ZooKeeper launch scripts support controlling the root logger by
> > setting an environment variable named ZOO_LOG4J_PROP.  The value gets
> > passed to the launched process as a -Dzookeeper.root.logger argument [2]:
> >
> >nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE
> > "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \
> >"-Dzookeeper.log.file=${ZOO_LOG_FILE}"
> > "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
> >-XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError='kill -9 %p' \
> >-cp "$CLASSPATH" $JVMFLAGS $ZOOMAIN "$ZOOCFG" > "$_ZOO_DAEMON_OUT"
> > 2>&1 < /dev/null &
> >
> > We have a Log4J 1 log4j.properties file that includes a default value for
> > zookeeper.root.logger in case it is unspecified at process launch, and
> > then the variable gets substituted into the declaration of
> > log4j.rootLogger [3]:
> >
> > zookeeper.root.logger=INFO, CONSOLE
> > ...
> > log4j.rootLogger=${zookeeper.root.logger}
> >
> > The net effect of this is that it gives the administrator the capability
> > to parameterize the appender at process launch time without needing to
> > edit the log4j.properties file.  For example, they could run
> > "ZOO_LOG4J_PROP=DEBUG,ROLLINGFILE; bin/zkServer.sh start".
> >
> > I have not been able to replicate this functionality in Log4J 2.  From
> > what I can tell, Log4J 2 configuration is more structured, so there are
> > specific individual settings for things like rootLogger.level and
> > rootLogger.appenderRefs.  There isn't a centralized spot where I can
> > substitute in "DEBUG,ROLLINGFILE" or similar as a single string to toggle
> > the settings.  That means that we'd have to advise administrators to
> > switch to a model of editing their log4j2.properties file to achieve this
> > instead of controlling it with the environment variable.  That would be
> > seen as a backwards-incompatible change from the administrator's
> > perspective.  I suppose an alternative could be to preserve the current
> > functionality by trying to implement our own logic to parse things like
> > "DEBUG,ROLLINGFILE" and translate to what Log4J 2 expects, but given the
> > amount of flexibility that was possible, I expect attempting to do this
> > would be brittle.
> >
> > Does anyone have other suggestions for how to implement this?  Is there a
> > Log4J 2 configuration feature that I failed to find that would be helpful
> > here?
> >
> > Thank you!
> >
> > --Chris Nauroth
> >
> > [1] https://issues.apache.org/jira/browse/ZOOKEEPER-2342
> > [2]
> >
> https://github.com/apache/zookeeper/blob/release-3.5.1/bin/zkServer.sh#L148
> > -L151
> > [3]
> >
> https://github.com/apache/zookeeper/blob/release-3.5.1/conf/log4j.propertie
> > s#L20-L33
> >
> >
> > -
> > 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
>
>