<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
You can also try to use the MDC (Message Diagnostic Context). This
at least is supported by log4j backends too.<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.slf4j.org/api/org/slf4j/MDC.html">http://www.slf4j.org/api/org/slf4j/MDC.html</a><br>
<a class="moz-txt-link-freetext" href="http://logback.qos.ch/manual/mdc.html">http://logback.qos.ch/manual/mdc.html</a><br>
<br>
It allows to set any property you want on your log message. The
log4j formatter can then output these in a special column.<br>
I think MDC is a great tool for business tracing as you can also set
attributes from the business logic like e.g. the current customer id
that is related to this processing.<br>
<br>
Christian<br>
<br>
Am 11.05.2012 14:54, schrieb William Shatner:
<blockquote
cite="mid:CACq1U7wGL+dFYqU6vQrRPio5Zi4MGzcp8VSV=_CEjPvD5GUoKA@mail.gmail.com"
type="cite">Hi,<br>
<br>
Yes I understand that..but they will not get outputted so i dont
get any extra tracing benefit unless they use logback.<br>
<br>
Thanks again,<br>
W<br>
<br>
<div class="gmail_quote">On Fri, May 11, 2012 at 1:50 PM, ceki <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ceki@qos.ch" target="_blank">ceki@qos.ch</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Markers are part of the SLF4J API. Thus, whereas logback can
filter on<br>
markers, with other logging frameworks such as log4j and
j.u.l, your<br>
markers will simply be ignored. Markers do not tie you or your
users<br>
to logback.<br>
<br>
By the way, SLF4J already comes with a level called TRACE.<br>
<br>
On 11.05.2012 14:42, William Shatner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
HI Guys,<br>
<br>
Thanks for the replies. What I'm trying to do is implement a
tracing<br>
module for my application with x levels of tracing that
users can set<br>
(e.g basic, return types, parameters and so on...). We
already use slf4j<br>
for logging purposes and we intend using slf4j to output our
tracing too.<br>
<br>
Due to various issues with our application tracing levels
(our custome<br>
defined tracing levels - not logging levels) and monitoring
local<br>
attributes to change this tracing level... and tie-ing this
to slff4j<br>
log levels and then setting up loggers to handle this on
application<br>
server the idea was to add more levels to slf4j so that the
log<br>
level/trace level; could be handled/set by the application
server<br>
setting e.g set to FINER and so on will get x level of
tracing on this<br>
Logger handler.. perhaps logger.infoPlus was a bad example.<br>
<br>
The reason we are using slf4j is it allows applications
using our<br>
"application" (it's really just a library that other
applications use)<br>
use whatever logging implementation they want.<br>
<br>
If I use Markers i think this ties everybody to logback- and
is still<br>
not really what I'm looking for<br>
<br>
Anyway, i don't think using standard levels available on
Jboss such as<br>
Fine,Finer etc changes things too much from logger.errorPlus
....and<br>
your answers are still relevant...<br>
<br>
Thanks for the replies, any other ideas are welcome.<br>
<br>
Thanks,<br>
Will<br>
<br>
On Fri, May 11, 2012 at 12:35 PM, ceki <<a
moz-do-not-send="true" href="mailto:ceki@qos.ch"
target="_blank">ceki@qos.ch</a><br>
<mailto:<a moz-do-not-send="true"
href="mailto:ceki@qos.ch" target="_blank">ceki@qos.ch</a>>>
wrote:<br>
<br>
On 11.05.2012 12:47, Robert Elliot wrote:<br>
<br>
> Short answer: no.<br>
><br>
> Longer answer:<br>
><br>
> The point of SLF4J is it's a common facade or
interface, you then<br>
<br>
> choose an implementation (logback, slf4j-log4j,
slf4j-jdk14 etc.).<br>
> Obviously the existing implementations only know
about & support the<br>
> levels defined on the existing interface.<br>
<br>
Yep, as indicates (or fails to indicate) SLF4J is just an
abstraction<br>
layer for logging frameworks.<br>
<br>
<br>
> Obviously you could write your own interface that
extends the slf4j<br>
> Logger interface and adds those methods, but what
would you do with<br>
> the calls to them? To get support for new levels
you would need to<br>
> write your own implementation which implements your
new interface<br>
with<br>
> its new methods. You'd then have a coupling
between your custom<br>
> implementation and your custom extension of the
SLF4J interface, and<br>
<br>
> in all probability a tight coupling from your
custom<br>
implementation to<br>
> an existing logging subsystem that supports
defining new levels.<br>
<br>
The above could be seen as a critique of abstraction
layers or at<br>
least it highlights the difficulty of getting
abstractions layers<br>
right.<br>
<br>
<br>
> I believe Markers are intended to support some of
the use cases that<br>
> might otherwise be achieved by custom log levels.<br>
<br>
Correct. Markers give you a another dimension for
filtering<br>
events. Instead of the infoPlus level, you would use the
PLUS<br>
marker. SLF4J support the following syntax:<br>
<br>
Marker PLUS = MarkerFactory.getMarker("PLUS"__);<br>
<a moz-do-not-send="true" href="http://logger.info"
target="_blank">logger.info</a> <<a
moz-do-not-send="true" href="http://logger.info"
target="_blank">http://logger.info</a>>(PLUS, "some
message");<br>
<br>
HTH,<br>
--<br>
Ceki<br>
<a moz-do-not-send="true"
href="http://twitter.com/#%21/ceki" target="_blank">http://twitter.com/#!/ceki</a>
<<a moz-do-not-send="true"
href="http://twitter.com/#%21/ceki" target="_blank">http://twitter.com/#%21/ceki</a>><br>
<br>
<br>
----- Original Message -----<br>
<br>
From: "William Shatner"<shatner.william@__<a
moz-do-not-send="true" href="http://gmail.com"
target="_blank">gmail.com</a><br>
<mailto:<a moz-do-not-send="true"
href="mailto:shatner.william@gmail.com" target="_blank">shatner.william@gmail.com</a>>><br>
To: <a moz-do-not-send="true"
href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a>
<mailto:<a moz-do-not-send="true"
href="mailto:slf4j-user@qos.ch" target="_blank">slf4j-user@qos.ch</a>><br>
Sent: Friday, 11 May, 2012 11:27:33 AM<br>
Subject: [slf4j-user] Extend slf4j Tracing Levels<br>
Hi,<br>
<br>
Is it possible to extend slf4j tracing levels to
have more fine<br>
grained levels beyond the standard error,info
etc.<br>
<br>
e.g<br>
<br>
<a moz-do-not-send="true"
href="http://logger.info" target="_blank">logger.info</a>
<<a moz-do-not-send="true" href="http://logger.info"
target="_blank">http://logger.info</a>><br>
logger.infoPlus<br>
...<br>
logger.error<br>
logger.error1<br>
logger.error2<br>
<br>
..<br>
<br>
<br>
Thanks,<br>
Will<br>
<br>
<span class="HOEnZb"><font color="#888888">
</font></span></blockquote>
<span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Ceki<br>
<a moz-do-not-send="true"
href="http://twitter.com/#%21/ceki" target="_blank">http://twitter.com/#!/ceki</a><br>
_______________________________________________<br>
slf4j-user mailing list<br>
<a moz-do-not-send="true" href="mailto:slf4j-user@qos.ch"
target="_blank">slf4j-user@qos.ch</a><br>
<a moz-do-not-send="true"
href="http://mailman.qos.ch/mailman/listinfo/slf4j-user"
target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
</font></span></blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
slf4j-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a>
<a class="moz-txt-link-freetext" href="http://mailman.qos.ch/mailman/listinfo/slf4j-user">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Christian Schneider
<a class="moz-txt-link-freetext" href="http://www.liquid-reality.de">http://www.liquid-reality.de</a>
Open Source Architect
Talend Application Integration Division <a class="moz-txt-link-freetext" href="http://www.talend.com">http://www.talend.com</a> </pre>
</body>
</html>