On 2/23/2017 1:09 PM, Apache wrote:
> You shouldn’t be trying to modify the logger. You should be trying to modify
> the configuration. Take a look at
> http://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization
>
> <http://logging.apache.org/log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_Configuration_after_Initialization>.
> That example creates an appender and a logger and adds them. In your case,
> you would want to find loggerConfig associated with your logger by calling
> config.getLoggerConfig(“loggerName”). Then add the filter to that.
>
> That said, you should probably explain what you are actually trying to do.
> More often than not, dynamically updating the logging configuration is
> unnecessary as what you really want to do can be achieved other ways.
Thanks.
What I'm trying to do is to run JUnit testing of an old logging facade that I've
bridged to log4j-2.
In the test, I set a filter, and want to see that it worked.
While I have your attention, I'm bridging from a format that used the JUL
"CONFIG" level, and would like to know how to represent this in a "neutral" way
for modern loggers. (I'm thinking of SLF4J, Log4J, and LogBack). My thought is
to map CONFIG requests to INFO requests with a "Marker" identifying CONFIG.
Same goes for FINE/FINER - mapping to TRACE, with markers for the two
alternatives. To make this work, I'm implementing special "Filters" :-).
Is there a better way? I know you can introduce additional levels in Log4j-2,
but that doesn't seem to be supported in SLF4J and LogBack, and I'm looking for
a more universal approach.
Thanks. -Marshall
>
> Ralph
>
>> On Feb 23, 2017, at 9:39 AM, Marshall Schor <m...@schor.com> wrote:
>>
>> Hi,
>>
>> I'm writing test cases, using version 2.8 of Log4j.
>>
>> One test sets a filter on a logger.
>>
>> Looking (afterwards) at the logger, I see that the logger has a field:
>>
>> "privateConfig", and that has two fields for configuration info:
>>
>> - config (set to an instance of XmlConfiguration)
>> - loggerConfig (has the filter I set on the logger).
>>
>> The code for isEnabled in Logger (line 238):
>> public boolean isEnabled(final Level level, final Marker marker, final Object
>> message, final Throwable t) {
>> return privateConfig.filter(level, marker, message, t);
>> }
>>
>> privateConfig.filter() although it has both a "config" and a "loggerConfig",
>> only checks the config.
>>
>> The fact that I successfully used an API to set the loggerConfig with a
>> filter
>> is ignored.
>>
>> Should the design for privateConfig.filter() check both configs, or is there
>> some API call to "merge" the change I did that was recorded in the field
>> "loggerConfig" into the config stored in the field "config"?
>>
>> -Marshall Schor
>>
>> P.S., here's the API call I did to set a filter:
>>
>> // coreLogger is a cast of a normal logger, to enable the get() method
>> coreLogger.get().addFilter(myFilter);
>>
>> // not sure if this is needed, but did it anyways
>> coreLogger.getContext().updateLoggers();
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
