[slf4j-dev] Usage of Markers

[Szel, Zoltan]

> The issue is in what the benefit is in having Markers for each of the various kinds of alerts
There would be only one Marker implementation which would contain any information required(alertkey, level1/level2 classification etc) to send an alert. This would allow the flexibility to send different alerts with the same API(they can provide defaults, but it would not be enough given that different infrastructure components will send alerts with different properties).

>If you check out the SLF4J extensions you will find an EventLogger class that is meant to do this kind of >thing. It uses a Marker to categorize the log record as an Event. It then uses a companion EventData class to >capture the specific data related to the event.
I have checked it out and what I have found is that the EventData is simply logged as an xml via an SLF4J logger. This is insufficient for me because the companion data needs to be available in the appender itself, because he is the only one who knows how to interpret  them.

>The MDC is appropriate to capture information that would be common to any log record written during the >lifetime of the request.
agree

Regards,
Zoltan Szel
Morgan Stanley | IDEAS Practice Areas
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3978
Zoli.Szel at MorganStanley.com<mailto:Zoli.Szel at MorganStanley.com>
From: dev-bounces at slf4j.org [mailto:dev-bounces at slf4j.org] On Behalf Of Ralph Goers
Sent: Thursday, June 04, 2009 3:12 PM
To: slf4j developers list
Subject: Re: [slf4j-dev] Usage of Markers

The issue is in what the benefit is in having Markers for each of the various kinds of alerts. If you check out the SLF4J extensions you will find an EventLogger class that is meant to do this kind of thing. It uses a Marker to categorize the log record as an Event. It then uses a companion EventData class to capture the specific data related to the event. Documentation is in extensions.html.

The MDC is appropriate to capture information that would be common to any log record written during the lifetime of the request. The EventData is just for the single event.

Ralph

On Jun 4, 2009, at 4:03 AM, Szel, Zoltan wrote:


Hi all,

we are planning to build alerting functionality around the SLF4J API and we thought about leveraging the Marker API for this. The reason why we need Markers is simple, more information have to be provided to perform the required LoggingEvent => AlertEvent conversion. What I have in my mind is the following:
Create an Alert marker which implements the marker interface + have additional getters/setters to provide the required properties to the alerting appender. The usage would look like this:

Logger.error(new Alert(...),"The aircondition is down")

However this does not seems to be the recommended way for using Markers where you would consult with the MarkerFactory for the appropriate Marker instance(MarkerFactory.getMarker("ALERT")).

What's your thought on using Marker's in this way? If you see any problem with it what would you recommend to provide extra contextual data to the log message(MDC is not appropriate here given the amount of code one might have to write to populate the Map)?

Thanks for your help in advance!

Kind Regards,
Zoltan Szel
Morgan Stanley | IDEAS Practice Areas
Lechner Odon fasor 8 | Floor 07
Budapest, 1095
Phone: +36 1 881-3978
Zoli.Szel at MorganStanley.com<mailto:Zoli.Szel at MorganStanley.com>
________________________________
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. Morgan Stanley may monitor and store emails to the extent permitted by applicable law.
_______________________________________________
dev mailing list
dev at slf4j.org<mailto:dev at slf4j.org>
http://www.slf4j.org/mailman/listinfo/dev


--------------------------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. Morgan Stanley may monitor and store emails to the extent permitted by applicable law.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20090604/c72e8288/attachment.htm>