[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    Re: Logging Domains committed to sandbox (dodgy cvs spam email
From:       Jacob Kjome <hoju () visi ! com>
Date:       2007-03-31 19:27:03
Message-ID: 20070331192918.C0A7510FB007 () herse ! apache ! org
[Download RAW message or body]

At 04:16 PM 3/29/2007, you wrote:
 >
 >On 30/03/2007, at 1:11 AM, Jacob Kjome wrote:
 >
 >>
 >> Hi Paul,
 >>
 >> Are logging domains akin to Markers in the SLF4J/Logback world?
 >>
 >
 >I'm in dangerous territory here because I'm really unfamiliar with
 >SLFJ and logback, but having a browse on the logback docs I think
 >there is _some_ overlap, but I think Markers is taking the problem
 >from the other side.  If I read things correctly, Markers are a more
 >finer grained and defined in the configuration files, whereas  my
 >initial Domain mashup is compile-time (at the moment).  Markers is
 >certainly very powerful.  Annotations is just another way of grouping
 >things together.
 >

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.

Am I on track?

 >I purely wanted to experiment with Annotations and JMX and see if
 >there was a nice easier way to formulate the Domain concept in my own
 >mind and perhaps get the conversation rolling with something
 >concrete, and see if there was a mechanism by which it could
 >integrate in a backward-compatible way to log4j 1.2.x (because
 >there's a lot of that out there still).
 >

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?

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).

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?


Jake

 >Paul
 >
 >
 >
 >


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic