Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Mike Kienenberger
Ralph,

I gave it a try, I really did.

It wasn't as straight-forward as all that.

Here's what I finally got to compile, but even so, it never activated
my second configuration file.

At this point, I think I'm done working on the problem.  My other
solution is working.  Your points about not having attributes
specified on the second configuration in the local config file and not
being able to automatically reload have been noted, and I'll put them
into the configuration file.

There's definitely some work to be done to better support this kind of
configuration, and I suspect as we continue down the road that more
situations like this will appear.  Web containers were only the first
wave. :-)

final LoggerContext loggerContext = (LoggerContext)
LogManager.getContext(false);
final org.apache.logging.log4j.core.config.Configuration
originalConfiguration = loggerContext.getConfiguration();

final ConfigurationSource originalConfigurationSource =
originalConfiguration.getConfigurationSource();
// Can't use originalConfigurationSource directly as the
stream is no longer open.
final URI originalConfigurationURI =
originalConfigurationSource.getURI();
org.apache.logging.log4j.core.config.Configuration
originalConfigurationReloaded = null;
if (originalConfigurationSource != null)
{
final String name = "doesn't matter, not used";
originalConfigurationReloaded =
ConfigurationFactory.getInstance().getConfiguration(loggerContext,
name, originalConfigurationURI);
}

final ConfigurationSource localConfigurationSource = new
ConfigurationSource(new FileInputStream(log4jConfigFile), new
File(log4jConfigFile));
// Warning: current configuration being destroyed at this point.
final org.apache.logging.log4j.core.config.Configuration
localConfiguration
=
ConfigurationFactory.getInstance().getConfiguration(loggerContext,
localConfigurationSource);
// Bad generics.   is not compatible with

final List configurationList = new ArrayList<>(2);
configurationList.add(originalConfigurationReloaded);
configurationList.add(localConfiguration);
CompositeConfiguration compositeConfiguration = new
CompositeConfiguration(configurationList);

On Fri, Feb 9, 2018 at 7:19 PM, Ralph Goers  wrote:
> I mistyped below - MergeStrategies cannot be specified as Plugins. If you 
> want to use a different MergeStrategy you need to specify the class name in a 
> property named log4j.mergeStrategy. Note that the documentation at 
> http://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties
>  
> 
>  is incorrect. log4j2.mergeFactory will not work.
>
> Ralph
>
>
>> On Feb 9, 2018, at 5:06 PM, Ralph Goers  wrote:
>>
>> CompositeConfiguration tries to merge attributes for elements with the same 
>> name. CompositeConfiguration can be configured with a MergeStrategy to 
>> handle merging nodes in the configuration. It uses the DefaultMergeStrategy 
>> by default. See 
>> http://logging.apache.org/log4j/2.x/manual/configuration.html#CompositeConfiguration
>>  
>> 
>>  for details on how it works. If you don’t like something in the way it 
>> works you can copy it, modify it, give it a new Plugin name and then 
>> configure it to be used.
>>
>> Ralph
>>
>>> On Feb 9, 2018, at 3:02 PM, Mike Kienenberger  wrote:
>>>
>>> Ralph,
>>> Thank for looking at it.
>>> I will give your method for cloning and compositeConfiguring a try
>>> when I get a chance.
>>> What will happen if the local (2nd) configuration file has a root
>>> logger entry?  What gotchas should I worry about when merging two
>>> configurations together with a CompositeConfiguration?
>>>
>>> Am I reading it right that the last configuration specified would be
>>> used to provide the root logger?
>>>
>>> So for my example, I would want to make the cloned existing
>>> configuration the last one added in order to preserve the root logger
>>> from EVIL.jar?
>>>
>>>
>>>
>>> On Fri, Feb 9, 2018 at 4:50 PM, Ralph Goers  
>>> wrote:
 You are starting the local configuration. This is a bit of a problem. On 
 the one hand it is calling the start method of all the components you want 
 to add, so that is nice. On the other hand if your configuration specifies 
 a monitorInterval a WatchManager is going to be started to monitor that 
 file. If someone changes that file it will not properly reconfigure. We 
 might also add other things to the start method of AbstractConfiguration. 
 These are all going to be orphaned when the reference to the local 

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
I mistyped below - MergeStrategies cannot be specified as Plugins. If you want 
to use a different MergeStrategy you need to specify the class name in a 
property named log4j.mergeStrategy. Note that the documentation at 
http://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties 

 is incorrect. log4j2.mergeFactory will not work.

Ralph


> On Feb 9, 2018, at 5:06 PM, Ralph Goers  wrote:
> 
> CompositeConfiguration tries to merge attributes for elements with the same 
> name. CompositeConfiguration can be configured with a MergeStrategy to handle 
> merging nodes in the configuration. It uses the DefaultMergeStrategy by 
> default. See 
> http://logging.apache.org/log4j/2.x/manual/configuration.html#CompositeConfiguration
>  
> 
>  for details on how it works. If you don’t like something in the way it works 
> you can copy it, modify it, give it a new Plugin name and then configure it 
> to be used.
> 
> Ralph
> 
>> On Feb 9, 2018, at 3:02 PM, Mike Kienenberger  wrote:
>> 
>> Ralph,
>> Thank for looking at it.
>> I will give your method for cloning and compositeConfiguring a try
>> when I get a chance.
>> What will happen if the local (2nd) configuration file has a root
>> logger entry?  What gotchas should I worry about when merging two
>> configurations together with a CompositeConfiguration?
>> 
>> Am I reading it right that the last configuration specified would be
>> used to provide the root logger?
>> 
>> So for my example, I would want to make the cloned existing
>> configuration the last one added in order to preserve the root logger
>> from EVIL.jar?
>> 
>> 
>> 
>> On Fri, Feb 9, 2018 at 4:50 PM, Ralph Goers  
>> wrote:
>>> You are starting the local configuration. This is a bit of a problem. On 
>>> the one hand it is calling the start method of all the components you want 
>>> to add, so that is nice. On the other hand if your configuration specifies 
>>> a monitorInterval a WatchManager is going to be started to monitor that 
>>> file. If someone changes that file it will not properly reconfigure. We 
>>> might also add other things to the start method of AbstractConfiguration. 
>>> These are all going to be orphaned when the reference to the local 
>>> configuration is lost. So I really wouldn’t recommend calling start. In 
>>> fact, I really think the approach of copying the current configuration and 
>>> using the CompositeConfiguration is the safest way to accomplish what you 
>>> are wanting.
>>> 
>>> Ralph
>>> 
>>> 
>>> 
 On Feb 9, 2018, at 10:58 AM, Mike Kienenberger  wrote:
 
 Ralph,
 
 I was able to accomplish what I needed.   I think I prefer what I've
 done over trying to create a CompositeConfiguration as my current
 approach doesn't re-initialize the existing configuration and it gives
 me more control over how the additional configuration is merged into
 the existing configuration.
 
 I'm sure that the down-side is that I'm accessing non-public api and
 it will probably break down the road.
 
 I'm attaching the method I created.   Apologies for the braces on
 separate lines (code style of this project) and it's a little long but
 I think it's worth putting in the archives for future reference.
 
  /**
   * Reads file log4jConfigFile as an xml configuration file.
   * Adds Appenders and non-root loggers to the existing logging
 Configuration.
   * Root logger is ignored.
   * Currently does not support Filters or properties on Loggers.
   *
   * @param log4jConfigFile file name to read.
   */
  private static void updateLog4jConfiguration(final String log4jConfigFile)
  {
  try
  {
  final LoggerContext loggerContext = (LoggerContext)
 LogManager.getContext(false);
  final org.apache.logging.log4j.core.config.Configuration
 configuration = loggerContext.getConfiguration();
  LoggerConfig parentLoggerConfig = configuration.getRootLogger();
 
  final ConfigurationSource localConfigurationSource = new
 ConfigurationSource(new FileInputStream(log4jConfigFile), new
 File(log4jConfigFile));
  final XmlConfiguration localXmlConfiguration = new
 XmlConfiguration(null, localConfigurationSource);
 
  localXmlConfiguration.initialize();
  localXmlConfiguration.setup();
  localXmlConfiguration.start();
 
  final Map localAppenders =
 localXmlConfiguration.getAppenders();
  final Map localLoggers =
 localXmlConfiguration.getLoggers();
  final Collection localAppenderList =
 

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
CompositeConfiguration tries to merge attributes for elements with the same 
name. CompositeConfiguration can be configured with a MergeStrategy to handle 
merging nodes in the configuration. It uses the DefaultMergeStrategy by 
default. See 
http://logging.apache.org/log4j/2.x/manual/configuration.html#CompositeConfiguration
 

 for details on how it works. If you don’t like something in the way it works 
you can copy it, modify it, give it a new Plugin name and then configure it to 
be used.

Ralph

> On Feb 9, 2018, at 3:02 PM, Mike Kienenberger  wrote:
> 
> Ralph,
> Thank for looking at it.
> I will give your method for cloning and compositeConfiguring a try
> when I get a chance.
> What will happen if the local (2nd) configuration file has a root
> logger entry?  What gotchas should I worry about when merging two
> configurations together with a CompositeConfiguration?
> 
> Am I reading it right that the last configuration specified would be
> used to provide the root logger?
> 
> So for my example, I would want to make the cloned existing
> configuration the last one added in order to preserve the root logger
> from EVIL.jar?
> 
> 
> 
> On Fri, Feb 9, 2018 at 4:50 PM, Ralph Goers  
> wrote:
>> You are starting the local configuration. This is a bit of a problem. On the 
>> one hand it is calling the start method of all the components you want to 
>> add, so that is nice. On the other hand if your configuration specifies a 
>> monitorInterval a WatchManager is going to be started to monitor that file. 
>> If someone changes that file it will not properly reconfigure. We might also 
>> add other things to the start method of AbstractConfiguration. These are all 
>> going to be orphaned when the reference to the local configuration is lost. 
>> So I really wouldn’t recommend calling start. In fact, I really think the 
>> approach of copying the current configuration and using the 
>> CompositeConfiguration is the safest way to accomplish what you are wanting.
>> 
>> Ralph
>> 
>> 
>> 
>>> On Feb 9, 2018, at 10:58 AM, Mike Kienenberger  wrote:
>>> 
>>> Ralph,
>>> 
>>> I was able to accomplish what I needed.   I think I prefer what I've
>>> done over trying to create a CompositeConfiguration as my current
>>> approach doesn't re-initialize the existing configuration and it gives
>>> me more control over how the additional configuration is merged into
>>> the existing configuration.
>>> 
>>> I'm sure that the down-side is that I'm accessing non-public api and
>>> it will probably break down the road.
>>> 
>>> I'm attaching the method I created.   Apologies for the braces on
>>> separate lines (code style of this project) and it's a little long but
>>> I think it's worth putting in the archives for future reference.
>>> 
>>>   /**
>>>* Reads file log4jConfigFile as an xml configuration file.
>>>* Adds Appenders and non-root loggers to the existing logging
>>> Configuration.
>>>* Root logger is ignored.
>>>* Currently does not support Filters or properties on Loggers.
>>>*
>>>* @param log4jConfigFile file name to read.
>>>*/
>>>   private static void updateLog4jConfiguration(final String log4jConfigFile)
>>>   {
>>>   try
>>>   {
>>>   final LoggerContext loggerContext = (LoggerContext)
>>> LogManager.getContext(false);
>>>   final org.apache.logging.log4j.core.config.Configuration
>>> configuration = loggerContext.getConfiguration();
>>>   LoggerConfig parentLoggerConfig = configuration.getRootLogger();
>>> 
>>>   final ConfigurationSource localConfigurationSource = new
>>> ConfigurationSource(new FileInputStream(log4jConfigFile), new
>>> File(log4jConfigFile));
>>>   final XmlConfiguration localXmlConfiguration = new
>>> XmlConfiguration(null, localConfigurationSource);
>>> 
>>>   localXmlConfiguration.initialize();
>>>   localXmlConfiguration.setup();
>>>   localXmlConfiguration.start();
>>> 
>>>   final Map localAppenders =
>>> localXmlConfiguration.getAppenders();
>>>   final Map localLoggers =
>>> localXmlConfiguration.getLoggers();
>>>   final Collection localAppenderList =
>>> localAppenders.values();
>>>   for (final Appender appender : localAppenderList)
>>>   {
>>>   configuration.addAppender(appender);
>>>   }
>>> 
>>>   LoggerConfig localRootLoggerConfig = null;
>>>   final List newLoggerConfigList = new ArrayList<>();
>>> 
>>>   for (final LoggerConfig localFileProvidedLoggerConfig :
>>> localLoggers.values())
>>>   {
>>>   final List appenderRefsList =
>>> localFileProvidedLoggerConfig.getAppenderRefs();
>>>   final AppenderRef[] appenderRefsArray;
>>>   if (null != 

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Mike Kienenberger
Ralph,
Thank for looking at it.
I will give your method for cloning and compositeConfiguring a try
when I get a chance.
What will happen if the local (2nd) configuration file has a root
logger entry?  What gotchas should I worry about when merging two
configurations together with a CompositeConfiguration?

Am I reading it right that the last configuration specified would be
used to provide the root logger?

So for my example, I would want to make the cloned existing
configuration the last one added in order to preserve the root logger
from EVIL.jar?



On Fri, Feb 9, 2018 at 4:50 PM, Ralph Goers  wrote:
> You are starting the local configuration. This is a bit of a problem. On the 
> one hand it is calling the start method of all the components you want to 
> add, so that is nice. On the other hand if your configuration specifies a 
> monitorInterval a WatchManager is going to be started to monitor that file. 
> If someone changes that file it will not properly reconfigure. We might also 
> add other things to the start method of AbstractConfiguration. These are all 
> going to be orphaned when the reference to the local configuration is lost. 
> So I really wouldn’t recommend calling start. In fact, I really think the 
> approach of copying the current configuration and using the 
> CompositeConfiguration is the safest way to accomplish what you are wanting.
>
> Ralph
>
>
>
>> On Feb 9, 2018, at 10:58 AM, Mike Kienenberger  wrote:
>>
>> Ralph,
>>
>> I was able to accomplish what I needed.   I think I prefer what I've
>> done over trying to create a CompositeConfiguration as my current
>> approach doesn't re-initialize the existing configuration and it gives
>> me more control over how the additional configuration is merged into
>> the existing configuration.
>>
>> I'm sure that the down-side is that I'm accessing non-public api and
>> it will probably break down the road.
>>
>> I'm attaching the method I created.   Apologies for the braces on
>> separate lines (code style of this project) and it's a little long but
>> I think it's worth putting in the archives for future reference.
>>
>>/**
>> * Reads file log4jConfigFile as an xml configuration file.
>> * Adds Appenders and non-root loggers to the existing logging
>> Configuration.
>> * Root logger is ignored.
>> * Currently does not support Filters or properties on Loggers.
>> *
>> * @param log4jConfigFile file name to read.
>> */
>>private static void updateLog4jConfiguration(final String log4jConfigFile)
>>{
>>try
>>{
>>final LoggerContext loggerContext = (LoggerContext)
>> LogManager.getContext(false);
>>final org.apache.logging.log4j.core.config.Configuration
>> configuration = loggerContext.getConfiguration();
>>LoggerConfig parentLoggerConfig = configuration.getRootLogger();
>>
>>final ConfigurationSource localConfigurationSource = new
>> ConfigurationSource(new FileInputStream(log4jConfigFile), new
>> File(log4jConfigFile));
>>final XmlConfiguration localXmlConfiguration = new
>> XmlConfiguration(null, localConfigurationSource);
>>
>>localXmlConfiguration.initialize();
>>localXmlConfiguration.setup();
>>localXmlConfiguration.start();
>>
>>final Map localAppenders =
>> localXmlConfiguration.getAppenders();
>>final Map localLoggers =
>> localXmlConfiguration.getLoggers();
>>final Collection localAppenderList =
>> localAppenders.values();
>>for (final Appender appender : localAppenderList)
>>{
>>configuration.addAppender(appender);
>>}
>>
>>LoggerConfig localRootLoggerConfig = null;
>>final List newLoggerConfigList = new ArrayList<>();
>>
>>for (final LoggerConfig localFileProvidedLoggerConfig :
>> localLoggers.values())
>>{
>>final List appenderRefsList =
>> localFileProvidedLoggerConfig.getAppenderRefs();
>>final AppenderRef[] appenderRefsArray;
>>if (null != appenderRefsList)
>>{
>>appenderRefsArray = appenderRefsList.toArray(new
>> AppenderRef[appenderRefsList.size()]);
>>}
>>else
>>{
>>appenderRefsArray = new AppenderRef[0];
>>}
>>final List propertyList =
>> localFileProvidedLoggerConfig.getPropertyList();
>>final Property[] propertyArray;
>>if (null != propertyList)
>>{
>>propertyArray = propertyList.toArray(new
>> Property[propertyList.size()]);
>>}
>>else
>>{
>>propertyArray = new Property[0];
>>}
>>final LoggerConfig 

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
You are starting the local configuration. This is a bit of a problem. On the 
one hand it is calling the start method of all the components you want to add, 
so that is nice. On the other hand if your configuration specifies a 
monitorInterval a WatchManager is going to be started to monitor that file. If 
someone changes that file it will not properly reconfigure. We might also add 
other things to the start method of AbstractConfiguration. These are all going 
to be orphaned when the reference to the local configuration is lost. So I 
really wouldn’t recommend calling start. In fact, I really think the approach 
of copying the current configuration and using the CompositeConfiguration is 
the safest way to accomplish what you are wanting.

Ralph



> On Feb 9, 2018, at 10:58 AM, Mike Kienenberger  wrote:
> 
> Ralph,
> 
> I was able to accomplish what I needed.   I think I prefer what I've
> done over trying to create a CompositeConfiguration as my current
> approach doesn't re-initialize the existing configuration and it gives
> me more control over how the additional configuration is merged into
> the existing configuration.
> 
> I'm sure that the down-side is that I'm accessing non-public api and
> it will probably break down the road.
> 
> I'm attaching the method I created.   Apologies for the braces on
> separate lines (code style of this project) and it's a little long but
> I think it's worth putting in the archives for future reference.
> 
>/**
> * Reads file log4jConfigFile as an xml configuration file.
> * Adds Appenders and non-root loggers to the existing logging
> Configuration.
> * Root logger is ignored.
> * Currently does not support Filters or properties on Loggers.
> *
> * @param log4jConfigFile file name to read.
> */
>private static void updateLog4jConfiguration(final String log4jConfigFile)
>{
>try
>{
>final LoggerContext loggerContext = (LoggerContext)
> LogManager.getContext(false);
>final org.apache.logging.log4j.core.config.Configuration
> configuration = loggerContext.getConfiguration();
>LoggerConfig parentLoggerConfig = configuration.getRootLogger();
> 
>final ConfigurationSource localConfigurationSource = new
> ConfigurationSource(new FileInputStream(log4jConfigFile), new
> File(log4jConfigFile));
>final XmlConfiguration localXmlConfiguration = new
> XmlConfiguration(null, localConfigurationSource);
> 
>localXmlConfiguration.initialize();
>localXmlConfiguration.setup();
>localXmlConfiguration.start();
> 
>final Map localAppenders =
> localXmlConfiguration.getAppenders();
>final Map localLoggers =
> localXmlConfiguration.getLoggers();
>final Collection localAppenderList =
> localAppenders.values();
>for (final Appender appender : localAppenderList)
>{
>configuration.addAppender(appender);
>}
> 
>LoggerConfig localRootLoggerConfig = null;
>final List newLoggerConfigList = new ArrayList<>();
> 
>for (final LoggerConfig localFileProvidedLoggerConfig :
> localLoggers.values())
>{
>final List appenderRefsList =
> localFileProvidedLoggerConfig.getAppenderRefs();
>final AppenderRef[] appenderRefsArray;
>if (null != appenderRefsList)
>{
>appenderRefsArray = appenderRefsList.toArray(new
> AppenderRef[appenderRefsList.size()]);
>}
>else
>{
>appenderRefsArray = new AppenderRef[0];
>}
>final List propertyList =
> localFileProvidedLoggerConfig.getPropertyList();
>final Property[] propertyArray;
>if (null != propertyList)
>{
>propertyArray = propertyList.toArray(new
> Property[propertyList.size()]);
>}
>else
>{
>propertyArray = new Property[0];
>}
>final LoggerConfig newLoggerConfig =
> LoggerConfig.createLogger(localFileProvidedLoggerConfig.isAdditive(),
>localFileProvidedLoggerConfig.getLevel(),
>localFileProvidedLoggerConfig.getName(),
> 
> String.valueOf(localFileProvidedLoggerConfig.isIncludeLocation()),
>appenderRefsArray, propertyArray,
>configuration,
>localFileProvidedLoggerConfig.getFilter());
> 
>for (final AppenderRef appenderRef : appenderRefsList)
>{
>final Appender appender =
> localAppenders.get(appenderRef.getRef());
>if (null != appender)
>{
>

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
I think to get a copy of the configuration you could try to do:

ConfigurationSource source = configuration.getConfgurationSource();
Configuration configuration = null;
If (source != null) {
   LoggerContext context = LogManager.getContext(false);
   configuration = ConfigurationFactory.getInstance().getConfiguration(context, 
source);
}

If getConfigurationSource returns null it would normally mean it wasn’t 
configured from a file. This solution wouldn’t handle that case but from what 
you have asked for this should be good enough.
   

Ralph

> On Feb 9, 2018, at 10:37 AM, Ralph Goers  wrote:
> 
> Would you mind creating a Jira issue requesting that the clone method, or 
> some variation of it, be added to Configuration implementations?
> 
> Ralph
> 
>> On Feb 9, 2018, at 9:14 AM, Mike Kienenberger  wrote:
>> 
>> Doh! I thought you had provided me with the magic bullet. :)
>> 
>> Ok. I'll back to programmically registering info read from my
>> XmlConfiguration into the active Context.
>> 
>> On Fri, Feb 9, 2018 at 11:12 AM, Ralph Goers  
>> wrote:
>>> It occurs to me that there is a problem with my suggest in that you cannot 
>>> create a new Configuration using the currently active configuration as that 
>>> will cause problems. The current configuration needs to be cloned. I don’t 
>>> know if we have an easy way to do that.
>>> 
>>> Ralph
>>> 
 On Feb 9, 2018, at 9:08 AM, Ralph Goers  wrote:
 
 If you want to add to their configuration then you should use a 
 CompositeConfiguration. In that case I would get the current 
 configuration, create your own Configuration, add them both to a new 
 CompositeConfiguration and then call 
 Configurator.initialize(compositeConfiguration).
 
 Ralph
 
> On Feb 9, 2018, at 9:03 AM, Mike Kienenberger  wrote:
> 
> Thanks, Ralph,
> 
> While that does work (tested) and could be useful in some instances,
> it would require that we extract and keep synced the logging
> configuration from EVIL.jar, then append our own changes to it.  I can
> see how this will be helpful when I'm doing development in this
> environment.  But it doesn't meet the need of only changing logging so
> that our own module logs to a different location.
> 
> On Thu, Feb 8, 2018 at 7:26 PM, Ralph Goers  
> wrote:
>> If you want to replace the existing configuration you should be able to 
>> do:
>> 
>> Configurator.initialize(“MyApp”, “app-log4j2.xml”);
>> 
>> This will look for a file named app-log4j2.xml on the class path.
>> 
>> Ralph
>> 
>>> On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  
>>> wrote:
>>> 
>>> As others have reported in years past, the examples in the docs for
>>> 
>>> Programmatically Modifying the Current Configuration after 
>>> Initialization
>>> 
>>> are out of date.  They don't compile.  They don't work (affect the
>>> existing logging) even if you do fix the errors.
>>> 
>>> Here's my situation:
>>> 
>>> I am working in an environment with EVIL.JAR which includes a 
>>> log4j2.xml file.
>>> I can't change the jar.  I can't specific a System Property to override 
>>> it.
>>> 
>>> My code gets called as a loaded module long after the logging system
>>> is initialized.
>>> 
>>> I want logging in my own code to go to a different location, and
>>> preferably I'd like to read the configuration in from a log4j2.xml
>>> file so that anyone who uses my module isn't victim to the same evil
>>> hardcoded-logging practices of EVIL.JAR.
>>> 
>>> Creating an XMLConfiguration and initializing it lets me read the xml
>>> file easily enough.   Looping through the data gets me the Appenders,
>>> Filters and Loggers.   But I still can't use them to modify the
>>> existing configuration.
>>> 
>>> Another person took the approach of using JUL instead.  I hate JUL and
>>> I'd really rather not have to go down that route.
>>> 
>>> Thanks in advance.
>>> -Mike
>>> 
>>> -
>>> 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: 

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Mike Kienenberger
Ralph,

I was able to accomplish what I needed.   I think I prefer what I've
done over trying to create a CompositeConfiguration as my current
approach doesn't re-initialize the existing configuration and it gives
me more control over how the additional configuration is merged into
the existing configuration.

I'm sure that the down-side is that I'm accessing non-public api and
it will probably break down the road.

I'm attaching the method I created.   Apologies for the braces on
separate lines (code style of this project) and it's a little long but
I think it's worth putting in the archives for future reference.

/**
 * Reads file log4jConfigFile as an xml configuration file.
 * Adds Appenders and non-root loggers to the existing logging
Configuration.
 * Root logger is ignored.
 * Currently does not support Filters or properties on Loggers.
 *
 * @param log4jConfigFile file name to read.
 */
private static void updateLog4jConfiguration(final String log4jConfigFile)
{
try
{
final LoggerContext loggerContext = (LoggerContext)
LogManager.getContext(false);
final org.apache.logging.log4j.core.config.Configuration
configuration = loggerContext.getConfiguration();
LoggerConfig parentLoggerConfig = configuration.getRootLogger();

final ConfigurationSource localConfigurationSource = new
ConfigurationSource(new FileInputStream(log4jConfigFile), new
File(log4jConfigFile));
final XmlConfiguration localXmlConfiguration = new
XmlConfiguration(null, localConfigurationSource);

localXmlConfiguration.initialize();
localXmlConfiguration.setup();
localXmlConfiguration.start();

final Map localAppenders =
localXmlConfiguration.getAppenders();
final Map localLoggers =
localXmlConfiguration.getLoggers();
final Collection localAppenderList =
localAppenders.values();
for (final Appender appender : localAppenderList)
{
configuration.addAppender(appender);
}

LoggerConfig localRootLoggerConfig = null;
final List newLoggerConfigList = new ArrayList<>();

for (final LoggerConfig localFileProvidedLoggerConfig :
localLoggers.values())
{
final List appenderRefsList =
localFileProvidedLoggerConfig.getAppenderRefs();
final AppenderRef[] appenderRefsArray;
if (null != appenderRefsList)
{
appenderRefsArray = appenderRefsList.toArray(new
AppenderRef[appenderRefsList.size()]);
}
else
{
appenderRefsArray = new AppenderRef[0];
}
final List propertyList =
localFileProvidedLoggerConfig.getPropertyList();
final Property[] propertyArray;
if (null != propertyList)
{
propertyArray = propertyList.toArray(new
Property[propertyList.size()]);
}
else
{
propertyArray = new Property[0];
}
final LoggerConfig newLoggerConfig =
LoggerConfig.createLogger(localFileProvidedLoggerConfig.isAdditive(),
localFileProvidedLoggerConfig.getLevel(),
localFileProvidedLoggerConfig.getName(),

String.valueOf(localFileProvidedLoggerConfig.isIncludeLocation()),
appenderRefsArray, propertyArray,
configuration,
localFileProvidedLoggerConfig.getFilter());

for (final AppenderRef appenderRef : appenderRefsList)
{
final Appender appender =
localAppenders.get(appenderRef.getRef());
if (null != appender)
{
newLoggerConfig.addAppender(appender, null, null);
}
else
{
// TODO: handle logger missing appender
configuration error
}
}

if (newLoggerConfig.getName().isEmpty())
{
if (null != localRootLoggerConfig)
{
// TODO: handle multiple root loggers
configuration error
}
localRootLoggerConfig = newLoggerConfig;
}

newLoggerConfig.setLevel(newLoggerConfig.getLevel());
newLoggerConfigList.add(newLoggerConfig);
}

//if (null != localRootLoggerConfig)
//{
//localRootLoggerConfig.setParent(parentLoggerConfig);
//parentLoggerConfig = localRootLoggerConfig;
//
configuration.addLogger(localRootLoggerConfig.getName(),

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
Would you mind creating a Jira issue requesting that the clone method, or some 
variation of it, be added to Configuration implementations?

Ralph

> On Feb 9, 2018, at 9:14 AM, Mike Kienenberger  wrote:
> 
> Doh! I thought you had provided me with the magic bullet. :)
> 
> Ok. I'll back to programmically registering info read from my
> XmlConfiguration into the active Context.
> 
> On Fri, Feb 9, 2018 at 11:12 AM, Ralph Goers  
> wrote:
>> It occurs to me that there is a problem with my suggest in that you cannot 
>> create a new Configuration using the currently active configuration as that 
>> will cause problems. The current configuration needs to be cloned. I don’t 
>> know if we have an easy way to do that.
>> 
>> Ralph
>> 
>>> On Feb 9, 2018, at 9:08 AM, Ralph Goers  wrote:
>>> 
>>> If you want to add to their configuration then you should use a 
>>> CompositeConfiguration. In that case I would get the current configuration, 
>>> create your own Configuration, add them both to a new 
>>> CompositeConfiguration and then call 
>>> Configurator.initialize(compositeConfiguration).
>>> 
>>> Ralph
>>> 
 On Feb 9, 2018, at 9:03 AM, Mike Kienenberger  wrote:
 
 Thanks, Ralph,
 
 While that does work (tested) and could be useful in some instances,
 it would require that we extract and keep synced the logging
 configuration from EVIL.jar, then append our own changes to it.  I can
 see how this will be helpful when I'm doing development in this
 environment.  But it doesn't meet the need of only changing logging so
 that our own module logs to a different location.
 
 On Thu, Feb 8, 2018 at 7:26 PM, Ralph Goers  
 wrote:
> If you want to replace the existing configuration you should be able to 
> do:
> 
> Configurator.initialize(“MyApp”, “app-log4j2.xml”);
> 
> This will look for a file named app-log4j2.xml on the class path.
> 
> Ralph
> 
>> On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  wrote:
>> 
>> As others have reported in years past, the examples in the docs for
>> 
>> Programmatically Modifying the Current Configuration after Initialization
>> 
>> are out of date.  They don't compile.  They don't work (affect the
>> existing logging) even if you do fix the errors.
>> 
>> Here's my situation:
>> 
>> I am working in an environment with EVIL.JAR which includes a log4j2.xml 
>> file.
>> I can't change the jar.  I can't specific a System Property to override 
>> it.
>> 
>> My code gets called as a loaded module long after the logging system
>> is initialized.
>> 
>> I want logging in my own code to go to a different location, and
>> preferably I'd like to read the configuration in from a log4j2.xml
>> file so that anyone who uses my module isn't victim to the same evil
>> hardcoded-logging practices of EVIL.JAR.
>> 
>> Creating an XMLConfiguration and initializing it lets me read the xml
>> file easily enough.   Looping through the data gets me the Appenders,
>> Filters and Loggers.   But I still can't use them to modify the
>> existing configuration.
>> 
>> Another person took the approach of using JUL instead.  I hate JUL and
>> I'd really rather not have to go down that route.
>> 
>> Thanks in advance.
>> -Mike
>> 
>> -
>> 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
>> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 




Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Mike Kienenberger
Doh! I thought you had provided me with the magic bullet. :)

Ok. I'll back to programmically registering info read from my
XmlConfiguration into the active Context.

On Fri, Feb 9, 2018 at 11:12 AM, Ralph Goers  wrote:
> It occurs to me that there is a problem with my suggest in that you cannot 
> create a new Configuration using the currently active configuration as that 
> will cause problems. The current configuration needs to be cloned. I don’t 
> know if we have an easy way to do that.
>
> Ralph
>
>> On Feb 9, 2018, at 9:08 AM, Ralph Goers  wrote:
>>
>> If you want to add to their configuration then you should use a 
>> CompositeConfiguration. In that case I would get the current configuration, 
>> create your own Configuration, add them both to a new CompositeConfiguration 
>> and then call Configurator.initialize(compositeConfiguration).
>>
>> Ralph
>>
>>> On Feb 9, 2018, at 9:03 AM, Mike Kienenberger  wrote:
>>>
>>> Thanks, Ralph,
>>>
>>> While that does work (tested) and could be useful in some instances,
>>> it would require that we extract and keep synced the logging
>>> configuration from EVIL.jar, then append our own changes to it.  I can
>>> see how this will be helpful when I'm doing development in this
>>> environment.  But it doesn't meet the need of only changing logging so
>>> that our own module logs to a different location.
>>>
>>> On Thu, Feb 8, 2018 at 7:26 PM, Ralph Goers  
>>> wrote:
 If you want to replace the existing configuration you should be able to do:

 Configurator.initialize(“MyApp”, “app-log4j2.xml”);

 This will look for a file named app-log4j2.xml on the class path.

 Ralph

> On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  wrote:
>
> As others have reported in years past, the examples in the docs for
>
> Programmatically Modifying the Current Configuration after Initialization
>
> are out of date.  They don't compile.  They don't work (affect the
> existing logging) even if you do fix the errors.
>
> Here's my situation:
>
> I am working in an environment with EVIL.JAR which includes a log4j2.xml 
> file.
> I can't change the jar.  I can't specific a System Property to override 
> it.
>
> My code gets called as a loaded module long after the logging system
> is initialized.
>
> I want logging in my own code to go to a different location, and
> preferably I'd like to read the configuration in from a log4j2.xml
> file so that anyone who uses my module isn't victim to the same evil
> hardcoded-logging practices of EVIL.JAR.
>
> Creating an XMLConfiguration and initializing it lets me read the xml
> file easily enough.   Looping through the data gets me the Appenders,
> Filters and Loggers.   But I still can't use them to modify the
> existing configuration.
>
> Another person took the approach of using JUL instead.  I hate JUL and
> I'd really rather not have to go down that route.
>
> Thanks in advance.
> -Mike
>
> -
> 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
>

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



Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Mike Kienenberger
Volker,

Great to hear from you.

Yes, that does work, and at least resolves my "configure loggers" part
of the issue.   I can't rely on knowing any logger name from the
original configuration file using
configuration.getLoggerConfig(loggerName), but .getRootLogger() worked
for me.  Registering it under a parent logging config seemed to be the
missing step.

If I can get the appenders in my file registered with the existing
configuration, that will probably be sufficient for my current needs.
 Filters would be nice, but are not required yet at this point.
Still working through this part.

Ralph,

CompositeConfiguration sounds even better.  I'll give that a try first.

On Fri, Feb 9, 2018 at 3:21 AM, Volker Weber  wrote:
> Hi Mike,
>
> in our app we implemented a REST-Service to reconfigure log4j2 at runtime.
>
> It's mainly to apply changes to the configuration and call updateLoggers()
>
> LoggerContext loggerContext = (LoggerContext)
> LogManager.getContext(false);
> Configuration configuration = loggerContext.getConfiguration();
> LoggerConfig loggerConfig = configuration.getLoggerConfig(loggerName);
> LoggerConfig specificConfig = loggerConfig;
>
> if (!loggerConfig.getName().equals(loggerName)) {
>   specificConfig = new LoggerConfig(loggerName, level, true);
>   specificConfig.setParent(loggerConfig);
>   configuration.addLogger(loggerName, specificConfig);
> }
> specificConfig.setLevel(level);
> loggerContext.updateLoggers();
>
> see attachment for our full Log4j2Util code.
>
> Regards,
>   Volker
>
>
>
> 2018-02-08 21:28 GMT+01:00 Mike Kienenberger :
>>
>> As others have reported in years past, the examples in the docs for
>>
>> Programmatically Modifying the Current Configuration after Initialization
>>
>> are out of date.  They don't compile.  They don't work (affect the
>> existing logging) even if you do fix the errors.
>>
>> Here's my situation:
>>
>> I am working in an environment with EVIL.JAR which includes a log4j2.xml
>> file.
>> I can't change the jar.  I can't specific a System Property to override
>> it.
>>
>> My code gets called as a loaded module long after the logging system
>> is initialized.
>>
>> I want logging in my own code to go to a different location, and
>> preferably I'd like to read the configuration in from a log4j2.xml
>> file so that anyone who uses my module isn't victim to the same evil
>> hardcoded-logging practices of EVIL.JAR.
>>
>> Creating an XMLConfiguration and initializing it lets me read the xml
>> file easily enough.   Looping through the data gets me the Appenders,
>> Filters and Loggers.   But I still can't use them to modify the
>> existing configuration.
>>
>> Another person took the approach of using JUL instead.  I hate JUL and
>> I'd really rather not have to go down that route.
>>
>> Thanks in advance.
>> -Mike
>>
>> -
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>
>
>
> --
> inexso - information exchange solutions GmbH
> Ofener Straße 30 | 26121 Oldenburg
> www.inexso.de
>
>
> -
> 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: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
It occurs to me that there is a problem with my suggest in that you cannot 
create a new Configuration using the currently active configuration as that 
will cause problems. The current configuration needs to be cloned. I don’t know 
if we have an easy way to do that.

Ralph

> On Feb 9, 2018, at 9:08 AM, Ralph Goers  wrote:
> 
> If you want to add to their configuration then you should use a 
> CompositeConfiguration. In that case I would get the current configuration, 
> create your own Configuration, add them both to a new CompositeConfiguration 
> and then call Configurator.initialize(compositeConfiguration).
> 
> Ralph
> 
>> On Feb 9, 2018, at 9:03 AM, Mike Kienenberger  wrote:
>> 
>> Thanks, Ralph,
>> 
>> While that does work (tested) and could be useful in some instances,
>> it would require that we extract and keep synced the logging
>> configuration from EVIL.jar, then append our own changes to it.  I can
>> see how this will be helpful when I'm doing development in this
>> environment.  But it doesn't meet the need of only changing logging so
>> that our own module logs to a different location.
>> 
>> On Thu, Feb 8, 2018 at 7:26 PM, Ralph Goers  
>> wrote:
>>> If you want to replace the existing configuration you should be able to do:
>>> 
>>> Configurator.initialize(“MyApp”, “app-log4j2.xml”);
>>> 
>>> This will look for a file named app-log4j2.xml on the class path.
>>> 
>>> Ralph
>>> 
 On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  wrote:
 
 As others have reported in years past, the examples in the docs for
 
 Programmatically Modifying the Current Configuration after Initialization
 
 are out of date.  They don't compile.  They don't work (affect the
 existing logging) even if you do fix the errors.
 
 Here's my situation:
 
 I am working in an environment with EVIL.JAR which includes a log4j2.xml 
 file.
 I can't change the jar.  I can't specific a System Property to override it.
 
 My code gets called as a loaded module long after the logging system
 is initialized.
 
 I want logging in my own code to go to a different location, and
 preferably I'd like to read the configuration in from a log4j2.xml
 file so that anyone who uses my module isn't victim to the same evil
 hardcoded-logging practices of EVIL.JAR.
 
 Creating an XMLConfiguration and initializing it lets me read the xml
 file easily enough.   Looping through the data gets me the Appenders,
 Filters and Loggers.   But I still can't use them to modify the
 existing configuration.
 
 Another person took the approach of using JUL instead.  I hate JUL and
 I'd really rather not have to go down that route.
 
 Thanks in advance.
 -Mike
 
 -
 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: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
If you want to add to their configuration then you should use a 
CompositeConfiguration. In that case I would get the current configuration, 
create your own Configuration, add them both to a new CompositeConfiguration 
and then call Configurator.initialize(compositeConfiguration).

Ralph

> On Feb 9, 2018, at 9:03 AM, Mike Kienenberger  wrote:
> 
> Thanks, Ralph,
> 
> While that does work (tested) and could be useful in some instances,
> it would require that we extract and keep synced the logging
> configuration from EVIL.jar, then append our own changes to it.  I can
> see how this will be helpful when I'm doing development in this
> environment.  But it doesn't meet the need of only changing logging so
> that our own module logs to a different location.
> 
> On Thu, Feb 8, 2018 at 7:26 PM, Ralph Goers  
> wrote:
>> If you want to replace the existing configuration you should be able to do:
>> 
>> Configurator.initialize(“MyApp”, “app-log4j2.xml”);
>> 
>> This will look for a file named app-log4j2.xml on the class path.
>> 
>> Ralph
>> 
>>> On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  wrote:
>>> 
>>> As others have reported in years past, the examples in the docs for
>>> 
>>> Programmatically Modifying the Current Configuration after Initialization
>>> 
>>> are out of date.  They don't compile.  They don't work (affect the
>>> existing logging) even if you do fix the errors.
>>> 
>>> Here's my situation:
>>> 
>>> I am working in an environment with EVIL.JAR which includes a log4j2.xml 
>>> file.
>>> I can't change the jar.  I can't specific a System Property to override it.
>>> 
>>> My code gets called as a loaded module long after the logging system
>>> is initialized.
>>> 
>>> I want logging in my own code to go to a different location, and
>>> preferably I'd like to read the configuration in from a log4j2.xml
>>> file so that anyone who uses my module isn't victim to the same evil
>>> hardcoded-logging practices of EVIL.JAR.
>>> 
>>> Creating an XMLConfiguration and initializing it lets me read the xml
>>> file easily enough.   Looping through the data gets me the Appenders,
>>> Filters and Loggers.   But I still can't use them to modify the
>>> existing configuration.
>>> 
>>> Another person took the approach of using JUL instead.  I hate JUL and
>>> I'd really rather not have to go down that route.
>>> 
>>> Thanks in advance.
>>> -Mike
>>> 
>>> -
>>> 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: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Mike Kienenberger
Thanks, Ralph,

While that does work (tested) and could be useful in some instances,
it would require that we extract and keep synced the logging
configuration from EVIL.jar, then append our own changes to it.  I can
see how this will be helpful when I'm doing development in this
environment.  But it doesn't meet the need of only changing logging so
that our own module logs to a different location.

On Thu, Feb 8, 2018 at 7:26 PM, Ralph Goers  wrote:
> If you want to replace the existing configuration you should be able to do:
>
> Configurator.initialize(“MyApp”, “app-log4j2.xml”);
>
> This will look for a file named app-log4j2.xml on the class path.
>
> Ralph
>
>> On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  wrote:
>>
>> As others have reported in years past, the examples in the docs for
>>
>> Programmatically Modifying the Current Configuration after Initialization
>>
>> are out of date.  They don't compile.  They don't work (affect the
>> existing logging) even if you do fix the errors.
>>
>> Here's my situation:
>>
>> I am working in an environment with EVIL.JAR which includes a log4j2.xml 
>> file.
>> I can't change the jar.  I can't specific a System Property to override it.
>>
>> My code gets called as a loaded module long after the logging system
>> is initialized.
>>
>> I want logging in my own code to go to a different location, and
>> preferably I'd like to read the configuration in from a log4j2.xml
>> file so that anyone who uses my module isn't victim to the same evil
>> hardcoded-logging practices of EVIL.JAR.
>>
>> Creating an XMLConfiguration and initializing it lets me read the xml
>> file easily enough.   Looping through the data gets me the Appenders,
>> Filters and Loggers.   But I still can't use them to modify the
>> existing configuration.
>>
>> Another person took the approach of using JUL instead.  I hate JUL and
>> I'd really rather not have to go down that route.
>>
>> Thanks in advance.
>> -Mike
>>
>> -
>> 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: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Ralph Goers
Volker,

It looks like Configurator.setLevel(String loggerName, Level level) will do the 
same thing as the code below.

Ralph

> On Feb 9, 2018, at 1:21 AM, Volker Weber  wrote:
> 
> Hi Mike,
> 
> in our app we implemented a REST-Service to reconfigure log4j2 at runtime. 
> 
> It's mainly to apply changes to the configuration and call updateLoggers()
> 
> LoggerContext loggerContext = (LoggerContext) 
> LogManager.getContext(false);
> Configuration configuration = loggerContext.getConfiguration();
> LoggerConfig loggerConfig = configuration.getLoggerConfig(loggerName);
> LoggerConfig specificConfig = loggerConfig;
> 
> if (!loggerConfig.getName().equals(loggerName)) {
>   specificConfig = new LoggerConfig(loggerName, level, true);
>   specificConfig.setParent(loggerConfig);
>   configuration.addLogger(loggerName, specificConfig);
> }
> specificConfig.setLevel(level);
> loggerContext.updateLoggers();
> 
> see attachment for our full Log4j2Util code.
> 
> Regards,
>   Volker
> 
> 
> 
> 2018-02-08 21:28 GMT+01:00 Mike Kienenberger  >:
> As others have reported in years past, the examples in the docs for
> 
> Programmatically Modifying the Current Configuration after Initialization
> 
> are out of date.  They don't compile.  They don't work (affect the
> existing logging) even if you do fix the errors.
> 
> Here's my situation:
> 
> I am working in an environment with EVIL.JAR which includes a log4j2.xml file.
> I can't change the jar.  I can't specific a System Property to override it.
> 
> My code gets called as a loaded module long after the logging system
> is initialized.
> 
> I want logging in my own code to go to a different location, and
> preferably I'd like to read the configuration in from a log4j2.xml
> file so that anyone who uses my module isn't victim to the same evil
> hardcoded-logging practices of EVIL.JAR.
> 
> Creating an XMLConfiguration and initializing it lets me read the xml
> file easily enough.   Looping through the data gets me the Appenders,
> Filters and Loggers.   But I still can't use them to modify the
> existing configuration.
> 
> Another person took the approach of using JUL instead.  I hate JUL and
> I'd really rather not have to go down that route.
> 
> Thanks in advance.
> -Mike
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org 
> 
> For additional commands, e-mail: log4j-user-h...@logging.apache.org 
> 
> 
> 
> 
> 
> -- 
> inexso - information exchange solutions GmbH
> Ofener Straße 30 | 26121 Oldenburg
> www.inexso.de 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org



Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-09 Thread Volker Weber
Hi Mike,

in our app we implemented a REST-Service to reconfigure log4j2 at runtime.

It's mainly to apply changes to the configuration and call updateLoggers()

LoggerContext loggerContext = (LoggerContext)
LogManager.getContext(false);
Configuration configuration = loggerContext.getConfiguration();
LoggerConfig loggerConfig = configuration.getLoggerConfig(loggerName);
LoggerConfig specificConfig = loggerConfig;

if (!loggerConfig.getName().equals(loggerName)) {
  specificConfig = new LoggerConfig(loggerName, level, true);
  specificConfig.setParent(loggerConfig);
  configuration.addLogger(loggerName, specificConfig);
}
specificConfig.setLevel(level);
loggerContext.updateLoggers();

see attachment for our full Log4j2Util code.

Regards,
  Volker



2018-02-08 21:28 GMT+01:00 Mike Kienenberger :

> As others have reported in years past, the examples in the docs for
>
> Programmatically Modifying the Current Configuration after Initialization
>
> are out of date.  They don't compile.  They don't work (affect the
> existing logging) even if you do fix the errors.
>
> Here's my situation:
>
> I am working in an environment with EVIL.JAR which includes a log4j2.xml
> file.
> I can't change the jar.  I can't specific a System Property to override it.
>
> My code gets called as a loaded module long after the logging system
> is initialized.
>
> I want logging in my own code to go to a different location, and
> preferably I'd like to read the configuration in from a log4j2.xml
> file so that anyone who uses my module isn't victim to the same evil
> hardcoded-logging practices of EVIL.JAR.
>
> Creating an XMLConfiguration and initializing it lets me read the xml
> file easily enough.   Looping through the data gets me the Appenders,
> Filters and Loggers.   But I still can't use them to modify the
> existing configuration.
>
> Another person took the approach of using JUL instead.  I hate JUL and
> I'd really rather not have to go down that route.
>
> Thanks in advance.
> -Mike
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>


-- 
inexso - information exchange solutions GmbH
Ofener Straße 30 | 26121 Oldenburg
www.inexso.de
package de.inexso.commons.logging;

import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.core.appender.AbstractAppender;
import org.apache.logging.log4j.core.appender.ConsoleAppender;
import org.apache.logging.log4j.core.appender.FileAppender;
import org.apache.logging.log4j.core.config.Configuration;
import org.apache.logging.log4j.core.config.LoggerConfig;
import org.apache.logging.log4j.core.layout.PatternLayout;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Log4j2Util {

  private static final Logger LOG = LoggerFactory.getLogger(Log4j2Util.class);

  public static void setLoggerLevel(String loggerName, String levelName) throws IllegalArgumentException {
Level level = toLevel(levelName);
setLoggerLevel(loggerName, level);
  }

  public static Level toLevel(String levelName) throws IllegalArgumentException {
Level level = Level.toLevel(levelName, null);
if (level == null) {
  throw new IllegalArgumentException("Unknown levelName \"" + levelName + "\"");
}
return level;
  }

  public static void setLoggerLevel(Configuration configuration, String loggerName, String levelName)
  throws IllegalArgumentException {
setLoggerLevel(configuration, loggerName, toLevel(levelName));
  }

  public static void setLoggerLevel(String loggerName, Level level) {
LoggerContext loggerContext = (LoggerContext) LogManager.getContext(false);
Configuration configuration = loggerContext.getConfiguration();
setLoggerLevel(configuration, loggerName, level);
loggerContext.updateLoggers();
  }

  public static void setLoggerLevel(Configuration configuration, String loggerName, Level level) {
LoggerConfig loggerConfig = configuration.getLoggerConfig(loggerName);
LoggerConfig specificConfig = loggerConfig;

if (!loggerConfig.getName().equals(loggerName)) {
  specificConfig = new LoggerConfig(loggerName, level, true);
  specificConfig.setParent(loggerConfig);
  configuration.addLogger(loggerName, specificConfig);
}
specificConfig.setLevel(level);
  }

  public static void replaceRootAppender(Configuration configuration, String appenderName, String logFileName, String logLayout) {
AbstractAppender logAppender;
if ("STDOUT".equalsIgnoreCase(logFileName)) {
  logAppender = ConsoleAppender.newBuilder()
  .withLayout(PatternLayout.newBuilder().withPattern(logLayout).build())
  .withName(appenderName)
  .build();
} else {
  logAppender = 

Re: Programmatically Modifying the Current Configuration after Initialization

2018-02-08 Thread Ralph Goers
If you want to replace the existing configuration you should be able to do:

Configurator.initialize(“MyApp”, “app-log4j2.xml”);

This will look for a file named app-log4j2.xml on the class path.

Ralph

> On Feb 8, 2018, at 1:28 PM, Mike Kienenberger  wrote:
> 
> As others have reported in years past, the examples in the docs for
> 
> Programmatically Modifying the Current Configuration after Initialization
> 
> are out of date.  They don't compile.  They don't work (affect the
> existing logging) even if you do fix the errors.
> 
> Here's my situation:
> 
> I am working in an environment with EVIL.JAR which includes a log4j2.xml file.
> I can't change the jar.  I can't specific a System Property to override it.
> 
> My code gets called as a loaded module long after the logging system
> is initialized.
> 
> I want logging in my own code to go to a different location, and
> preferably I'd like to read the configuration in from a log4j2.xml
> file so that anyone who uses my module isn't victim to the same evil
> hardcoded-logging practices of EVIL.JAR.
> 
> Creating an XMLConfiguration and initializing it lets me read the xml
> file easily enough.   Looping through the data gets me the Appenders,
> Filters and Loggers.   But I still can't use them to modify the
> existing configuration.
> 
> Another person took the approach of using JUL instead.  I hate JUL and
> I'd really rather not have to go down that route.
> 
> Thanks in advance.
> -Mike
> 
> -
> 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