At 08:01 AM 4/1/2007, Paul Smith wrote:
[snip]
Now, back to the discussion:
Markers appear to allow one to decorate a single Logging event in a
point in code with a specific marker, and I'm assuming here that one
could come up with some sort of Composite Marker that would allow a
single event to belong to several dimensions (i'll use 'dimensions'
here simply to disambiguate Markers with my 'Domain'
implementation). This is where I think Markers are more fined
grained, because I can see a place in code looking like this (in
purely psuedo-code because I haven't played with Markers yet):
logger.debug( {"timing", "search", "documents"}, "Document search
took " + timing + "ms to execute");
Markers are already composite. They can be nested
multiple times. So instead of the above, you could write:
Marker myMarker = MarkerFactory.getMarker("MY_MARKER);
Marker timing= MarkerFactory.getMarker("TIMING);
Marker search= MarkerFactory.getMarker("SEARCH);
Marker documents = MarkerFactory.getMarker("DOCUMENTS);
myMarker.addChild(timing);
myMarker.addChild(search);
myMarker.addChild(documents );
logger.debug(myMarker, "Document search took " + timing + "ms to execute");
or better yet,
logger.debug(myMarker, "Document search took {} ms to execute", timing);
Imagine the above logging statement belonged to a Class called
com.mycompany.documents.DocSearch. It has a Logger as part of it's
package name hierarchy, plus that single logging statement declares
that the logging event belongs to some other dimensions related to
timings, an imaginary overall Search architecture, and specifically
some documents module within an application.
The Annotation-based method can't handle this finer-grained nature of
timing. With Annotations on the class, you can only describe where
the entire classes' Logging Statements fit in, so in the above
example I can probably annotate DocSearch with "search" and with
"documents", but I can't imply that every logging statement in this
class belongs to Timing because that wouldn't be accurate. However I
can add some dimension to all Logger statements with one annotation
rather than need to specify it with every logging statement.
Yep, that's the gist of it. Markers are more
accurate while annotated loggers are wholesale (thus maybe more convenient).
The way you have implemented domains to be compatible with
Log4j-1.2.xx is certainly compelling. However, the future seems to
be markers. I wonder if it would be more helpful to simply call
this an implementation of markers where the usage is more
prescribed and makes it unnecessary to pass markers via the Logger
API. In future versions of Log4j, which might support markers (as,
maybe, a result of supporting the SLF4J API), additional markers
may be supplied via the Logger API in addition to those defined as
annotations?
I wonder whether Markers and Annotations could work together.
Imagine something like this:
@LoggingDomains( domains="search", "documents")
public class DocSearch {
private static final Logger LOG = Logger.getLogger(DocSearch.class);
...
public void search(){
...
LOG.info( {"timing"}, "The Doc Search took " + time + "ms");
If at the point of Logger declaration the Logger class could inspect
the class for the annotation and pre-register a set of Markers used
for every logging statement, and at the point of logging, add any
additionally supplied Markers.
Markers are starting to sound like they have a relationship with
event Properties.
Yah, you could consider a marker as an event
property whereas domain is a logger property.
In principle, nothing prevents a marker to be applied on a logger.
For example, one could write:
@Marker( contains={"search", "documents"})
public class DocSearch {
private static final Logger LOG = Logger.getLogger(DocSearch.class);
Marker TIMING = MarkerFactory.getMarker("TIMING")l
...
public void search(){
...
LOG.info( TIMING, "The Doc Search took " + time + "ms");
[snip]
If my code does nothing more than stimulate some discussion and is
thrown out in favour of other ideas, then it has accomplished one of
my goals. :)
Your code was quite thought provoking. In a way,
it allows one to decorate a class with a marker
which could be pretty useful indeed.
cheers,
Paul Smith
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
