Yes, that sounds like a better approach than what I was suggesting. Can you create a jira ticket on making SiftingAppender more subclass friendly?
Can you make the changes you need to make SiftingAppendrBase more subclass friendly and put them in a pull request. I can have a look. And hopefully, Ceki willing, we can get the changes merged in. David On 19 Apr 2013, at 16:40, "Konstantinidis, Johannes" <[email protected]> wrote: > Hi David, > > thanks for the answer. > > I thought about subclassing the Sifting Appender because the SiftingAppender > and its configuration offer nearly everything I need. If I add a new > appender, it would at least need the name of the SiftingAppender. So I would > need an Action and a description how to configure, while the SiftingAppender > configuration is standard and has been described already. > > In addition, as mentioned before in another conversation on this list, the > SiftingAppender creates a sub appender only if there is at least one message > for the sub appender. So wouldn't I run into the same problem to just send a > dummy message to create the appender. Otherwise the valueList would not > contain the appender, would it? > > Btw, I have a working "subclass" of SiftingAppender that does the job. > Because of the package-private code in SiftingAppenderBase it is more like a > copy than a subclass :-) It would be helpful to split the > SiftingAppenderBase's append(..) method into two parts: > - get discriminating value > - get appender and doAppend > So a subclass can use the first method to get the discriminating value and > manipulate it and the second method to append to one or more appenders. > > Regards, > Johannes > > > -----Ursprüngliche Nachricht----- > Von: Logback-user [mailto:[email protected]] Im Auftrag von > diroussel > Gesendet: Freitag, 19. April 2013 15:10 > An: [email protected] > Betreff: Re: [logback-user] How to send one event to more than one appender > using the SiftingAppender? > > Johannes, > > I can't see how that would work at the moment. > > SiftingAppender keeps it's child appenders, and when a log events comes in > it will only log to one of them. > > I suppose, if you can write a custom appender that gets a reference to the > SiftingAppender, then you can do this: > > class FanOutAppender implements Appender { > SiftingAppender sift; > void doAppend(E event) { > // Fan out log event to all child appenders of sift > for (Appender a : sift.getAppenderTracker().valueList()) { > a.doAppend(event); > ) > } > } > > And that will log to all appenders. The trick is using filters so your log > event goes to either the sifting appender or your custom FanOutAppender > > David > > > > -- > View this message in context: > http://logback.10977.n7.nabble.com/How-to-send-one-event-to-more-than-one-appender-using-the-SiftingAppender-tp12011p12029.html > Sent from the Users mailing list archive at Nabble.com. > _______________________________________________ > Logback-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user > > ________________________________ > > Firma: Capgemini Deutschland GmbH > Geschäftsführer: Dr. Michael Schulte (Sprecher) • Dr. Uwe Dumslaff • Josef > Ranner > Aufsichtsratsvorsitzender: Antonio Schnieder > Amtsgericht Berlin-Charlottenburg, HRB 98814 > This message contains information that may be privileged or confidential and > is the property of the Capgemini Group. It is intended only for the person to > whom it is addressed. If you are not the intended recipient, you are not > authorized to read, print, retain, copy, disseminate, distribute, or use this > message or any part thereof. If you receive this message in error, please > notify the sender immediately and delete all copies of this message. > _______________________________________________ > Logback-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
