Markers would work but I wouldn’t recommend using them with SLF4J. See https://jira.qos.ch/browse/SLF4J-240 <https://jira.qos.ch/browse/SLF4J-240>. It has been open for over 5 years so I’m of the impression it will never be fixed. http://logging.apache.org/log4j/2.x/performance.html#Advanced_Filtering <http://logging.apache.org/log4j/2.x/performance.html#Advanced_Filtering> shows that filtering on Markers becomes a huge bottleneck in a multithreaded system.
Ralph > On Feb 23, 2017, at 1:01 PM, Marshall Schor <m...@schor.com> wrote: > > > > 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> >> >> <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 > <mailto:log4j-user-unsubscr...@logging.apache.org> > For additional commands, e-mail: log4j-user-h...@logging.apache.org > <mailto:log4j-user-h...@logging.apache.org>
