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
