Actually, that would be a good use case to document on the web site. The example that is up there is completely contrived. I made it up just to have something to use to explain it. But a real-world example would probably be much better.
Ralph > On Feb 23, 2017, at 8:54 PM, Matt Sicker <boa...@gmail.com> wrote: > > I haven't used markers much, but I've finally figured out an interesting > use case for them at work: marking log messages to filter them into a Slack > message. Right now we've got people using random Slack libraries to post > messages in team channels to alert various things, yet a simple appender > plus marker filter would simplify this quite a bit. I'd imagine that some > people use differently named loggers or other tricks because they don't > know about markers in the first place. > > On 23 February 2017 at 21:44, Apache <ralph.go...@dslextreme.com> wrote: > >> Yeah, but it makes me wonder if anyone is using Markers. That bug was >> found over 5 years ago during performance testing of an app at my former >> employer when they were still using Logback. It received no votes in Jira >> and no one saying “me too”. If they were doing any kind of logging with the >> MarkerFilter in the configuration they would have noticed the problem >> during any performance testing. >> >> That said, I too am glad it is finally fixed. But between that and the >> improvements to the FileAppender we need to update the performance page. >> In my tests we are still coming out ahead but Logback is now much better >> than it was. >> >> Ralph >> >>> On Feb 23, 2017, at 8:33 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> That's good to hear! A lot of people still use SLF4J with Log4j 2, so >>> anything that makes them more performant is a nice bonus. >>> >>> On 23 February 2017 at 21:29, Apache <ralph.go...@dslextreme.com> wrote: >>> >>>> I tested SLF4J after the fix and on my computer the performance problem >>>> does seem to have been addressed and the code should now be thread safe. >>>> >>>> Ralph >>>> >>>>> On Feb 23, 2017, at 2:39 PM, 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-help@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 >>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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> >> >> >> >> --------------------------------------------------------------------- >> 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> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
