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<String, Appender> localAppenders = localXmlConfiguration.getAppenders(); final Map<String, LoggerConfig> localLoggers = localXmlConfiguration.getLoggers(); final Collection<Appender> localAppenderList = localAppenders.values(); for (final Appender appender : localAppenderList) { configuration.addAppender(appender); } LoggerConfig localRootLoggerConfig = null; final List<LoggerConfig> newLoggerConfigList = new ArrayList<>(); for (final LoggerConfig localFileProvidedLoggerConfig : localLoggers.values()) { final List<AppenderRef> appenderRefsList = localFileProvidedLoggerConfig.getAppenderRefs(); final AppenderRef[] appenderRefsArray; if (null != appenderRefsList) { appenderRefsArray = appenderRefsList.toArray(new AppenderRef[appenderRefsList.size()]); } else { appenderRefsArray = new AppenderRef[0]; } final List<Property> 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(), localRootLoggerConfig); // } for (LoggerConfig newLoggerConfig : newLoggerConfigList) { newLoggerConfig.setParent(parentLoggerConfig); configuration.addLogger(newLoggerConfig.getName(), newLoggerConfig); } loggerContext.updateLoggers(); } catch (final Exception e) { // TODO: handle configuration error } } On Fri, Feb 9, 2018 at 12:37 PM, Ralph Goers <ralph.go...@dslextreme.com> 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 <mkien...@gmail.com> 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 <ralph.go...@dslextreme.com> >> 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 <ralph.go...@dslextreme.com> 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 <mkien...@gmail.com> 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 <ralph.go...@dslextreme.com> >>>>> 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 <mkien...@gmail.com> >>>>>>> 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 >> >> > > > > --------------------------------------------------------------------- > 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