The SMTP appender would work well as a sample for that idea as we don't have a Slack appender yet (though I do have a ticket open for a generic HTTP appender which could be used as one).
Also, after the site is integrated, we can start talking about 2.8.1. On 23 February 2017 at 21:58, Apache <ralph.go...@dslextreme.com> wrote: > 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-unsubscribe@ > logging.apache.org > >>>>>>>>>>> For additional commands, e-mail: log4j-user-help@logging. > >>> apache.org > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ------------------------------------------------------------ > >>> --------- > >>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@ > logging.apache.org > >>>>> <mailto:log4j-user-unsubscr...@logging.apache.org> > >>>>>>>>> For additional commands, e-mail: log4j-user-help@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-help@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 > > -- Matt Sicker <boa...@gmail.com>
