For the CONFIG level, you could match it to the same one in log4j-jul: https://logging.apache.org/log4j/2.x/log4j-jul/apidocs/src-html/org/apache/logging/log4j/jul/LevelTranslator.html#line.43
On 23 February 2017 at 15:39, Apache <ralph.go...@dslextreme.com> wrote: > And that issue has now been marked closed. However, there are still a > couple of synchronized methods in there that are called on every filter > comparison so we will have to rerun our performance benchmarks to see if it > made a significant difference. > > Ralph > > > On Feb 23, 2017, at 2:30 PM, Apache <ralph.go...@dslextreme.com> wrote: > > > > Ceki obviously reads this list as he marked SLF4J-240 in progress right > after I posted the message below. Keep an eye on that for a fix. > > > > While your in there Ceki, the contains methods in BasicMarker aren’t > thread-safe. > > > > Ralph > > > >> On Feb 23, 2017, at 1:29 PM, Apache <ralph.go...@dslextreme.com> wrote: > >> > >> 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> > > > > > > > > --------------------------------------------------------------------- > > 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 > > -- Matt Sicker <boa...@gmail.com>
