Either that or create an sample in the examples project. Speaking of, that needs to move to its own repo. I think I should have time to get the Scala stuff linked to the web site this weekend. Maybe I can split out the examples too.
Ralph > On Feb 23, 2017, at 8:56 PM, Apache <ralph.go...@dslextreme.com> wrote: > > 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
