This depends on how your filters are set up. Remember, it works similar to firewall rules: if you Accept or Deny no other filters are checked as a decision has been made. So if you check GARY/GARY_THROWING first and deny based on that then whether GARY or GARY_THROWING is also a THROWING marker is irrelevant. If you check THROWING first and deny (or accept) based on that then GARY and/or GARY_THROWING are irrelevant.
Since GARY is not a parent of THROWING (and can’t be if THROWING is a parent of GARY), if an event is just marked as THROWING it would not be denied just because all GARY events are being denied. Ralph > On Mar 1, 2016, at 5:50 PM, Gary Gregory <[email protected]> wrote: > > Hi Ralph, > > Thank you for shedding light on this use case. > > I think we are close but I still am doubtful/puzzled. I have a class with > logger calls scattered all over, something like: > > logger.throwing(ex1); > ... > logger.debug(...); > ... > logger.throwing(ex2); > .... > logger.warn(GaryMarker, "...", objects); // GARY_MARKER > ... > logger.throwing(ex3); // GARY_MARKER (?) > .... > logger.warn("...", objects); > ... > logger.throwing(ex4); > .... > > What I want is do deny log events originating from lines commented with // > GARY_MARKER. > > If I define (1) GARY and (2) GARY_THROWING to inherit from THROWING, would > this work? Wouldn't I deny all the other throwing()s? > > Thank you, > Gary > > > On Tue, Mar 1, 2016 at 4:39 PM, Ralph Goers <[email protected] > <mailto:[email protected]>> wrote: > From that use case you also wouldn’t want GARY to have THROWING as a parent > since that isn’t always the case. You could create GARY_THROWING that has > both as parents. If you deny GARY before THROWING is checked the event will > be denied. > > Ralph > >> On Mar 1, 2016, at 5:35 PM, Gary Gregory <[email protected] >> <mailto:[email protected]>> wrote: >> >> I did not make my use case clear enough perhaps. I have one log event logged >> with warn() and a custom marker, say "GARY". I have a second log event >> logged with throwing() which internally uses the "THROWING" marker. >> >> I was hopping to filter on the same marker "GARY", but how? >> >> The only way I thought to do this now is for my custom marker to inherit >> from the Log4j Core "THROWING" marker, but that won't even work since >> filtering on "GARY" will not deny "THROWING". >> >> Thoughts? >> >> Gary >> >> On Tue, Mar 1, 2016 at 4:29 PM, Ralph Goers <[email protected] >> <mailto:[email protected]>> wrote: >> I don’t see the point of accepting an array of Markers since you can always >> create a Marker that has multiple parents - effectively making it an array >> of Markers. However, this relationship is meant to be permanent - which >> makes sense to me since you should only be using a Marker to mean a single >> thing in an application. >> >> What I don’t really understand is how one FooException is “softer” than >> another FooException. I do understand how throwing a Type1Exception might >> be more significant than a Type2Exception, but that might be better >> expressed in the Exception hierarchy than in Markers. >> >> I could certainly see creating an ExceptionPatternSelector that uses a >> PatternLayout that only prints the exception message for some exceptions and >> prints the stack trace for others. >> >> I suppose I could also see creating an ExceptionFilter that filters based on >> the exception type. >> >> I guess it just feels wrong to me for a developer to have to add a Marker to >> an exception event to somehow add more significance to the event. >> >> Ralph >> >>> On Mar 1, 2016, at 4:24 PM, Gary Gregory <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi All: >>> >>> Is the following an odd-ball use case or a super-niche use case, and should >>> we do anything about it. >>> >>> I have a part of our app that throws and logs an exception with the usual: >>> >>> logger.throwing(new FooException(...)); >>> >>> Elsewhere in this class and in the same method, I have softer errors for >>> which I log a warning with a a custom marker. >>> >>> What I really want is to be able to filter out both log events based on >>> this marker but not other kinds of events, hence the use of Markers. >>> >>> I cannot say: >>> >>> logger.throwing(myMarker, new FooException(...)); >>> >>> Our implementation marks throwing() log event (helpfully) with its own >>> THROWING_MARKER. >>> >>> I could make my custom marker a child of THROWING_MARKER, but that is >>> really not semantically correct, is smelly and therefore a nasty hack IMO. >>> >>> If I had a logger.throwing(Marker, Throwable); API, how would it work? >>> >>> I would say that LogEvent should hold an array of Markers, not a single one. >>> >>> What does this sound like to you all? Craziness or a power-user refinement? >>> >>> Let's only consider throwing() for now before we even think about adding >>> Logger APIs that take Marker[]s. >>> >>> Gary >>> >>> >>> -- >>> E-Mail: [email protected] <mailto:[email protected]> | >>> [email protected] <mailto:[email protected]> >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >>> Home: http://garygregory.com/ <http://garygregory.com/> >>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> >> >> >> -- >> E-Mail: [email protected] <mailto:[email protected]> | >> [email protected] <mailto:[email protected]> >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> > > > > -- > E-Mail: [email protected] <mailto:[email protected]> | > [email protected] <mailto:[email protected]> > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> > Home: http://garygregory.com/ <http://garygregory.com/> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
