Let me see if I understand. Markers are more "fine grained" because they are applied individually in each logger statement. For instance, in SLF4J, you would say...logger.debug(myMarker, "my message");"myMarker" could be a different marker each time, or it could always be the same. It's the possibility of being a different marker each time that makes it different from domains, right (besides no restriction on logger name with markers, as opposed to domains)? Domains are defined once as an annotation for the class. With markers, any number of domains might be used. Domains provides more definition around the intended use while markers are kind of open to interpretation. Of course domains don't affect the Logger api at all while markers do.
First off I just want to be clear that I'm not suggesting that my idea _is_ Logging Domains. I think there could easily be a hundred different ways to skin this cat, and the mashup I did is purely _a_ way that some _part_ of a problem that a single hierarchy of loggers can't really handle well can be tackled.
Back in what feels like 1947, Ceki and Mark mentioned the broad concept of Logging Domains, but it was never a fully defined idea at that point (at least in what I recall).
Secondly, I'm still new to this Markers thing, so those with more experience should come out point out where I go off the rails with anything I say.
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");
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.
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.
Using Annotations for anything immediately requires Java 5, but personally I think if we're going to make any progress at all beyond log 1.3 I'm really hoping we as a group decide on make Java 5 the minimum required runtime for anything > log4j 1.3. Supporting older JDK's is really, IMHO, a waste of time (awaits flames).
So, logging domains might simply be a specific prescribed usage of markers, implemented in such a way that it removes the requirement (though doesn't preclude the possibility) to pass markers along with Logger statements. And as far as configuration goes, standard support for configuring markers could apply equally to annotated domain markers or individual markers passed via logging statements. Configuration wouldn't need to care where the markers came from or how they were intended to be used. It would all be generic to configuration (assuming such configuration support was built into Log4j at some future point in time).
The point of configuration is a good one. With Domains or Markers you could still define some explicit dimension groupings for a Class Logger in a configuration file (as you can with logback Markers I think). Configuration gives you the flexibility of grouping things at runtime. I think in many applications the Annotation-based approach works well and is defined at the point the class is made, and one could probably supplement the grouping at runtime with a configuration file if needed.
Does this make sense? I haven't looked at the details of the implementation or anything, so what I described might be way off of what you have implemented. Do you see what I described as even possible? Might logging domains be written to the SLF4J API so that the concept could be used by any logging system supporting the concept of Markers or does it have to be Log4j specific?
I need to go and refresh myself on SLFJ, last time I looked Markers weren't there (a long time ago). I tried to design Domains so that it was not log4j specific. I wrote some log4j specific classes extending from a generics-based approach, and I think it would be simple to add a java.util.logging layer as well.
Jacob, I'd appreciate if you had some time to have a quick look at the code, it's pretty tiny, so wouldn't take too long, you've got more SL4J experience than me and can comment on this better than I can.
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. :)
cheers, Paul Smith
smime.p7s
Description: S/MIME cryptographic signature
