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
