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
