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

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

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

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

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

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 =

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

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.

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

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

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

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

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

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

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 =

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