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 <garydgregory@gmail.com> 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 <ralph.goers@dslextreme.com> 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 <garydgregory@gmail.com> 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




--