Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)

[Jacob Kjome <ho...@visi.com>]

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

Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)

[Ceki Gülcü <ce...@qos.ch>]

At 06:10 AM 4/2/2007, you wrote:
>My understanding of the motivation of "markers" is to provide a
>mechanism to provide explicit context (for example, IP address of
>current request) for a logging call which supplements the implicit
>context extracted from the current thread (contents of MDC and NDC,
>thread name, call stack).  The primary use for the explicit context
>is likely to provide information to be recorded in the log with a
>secondary use to provide information to be used by filters.

I am afraid that is not the motivation for Markers.

>The motivation of logging domains appears to be to identify concerns
>that cut across the established hierarchy and the expected use
>appears to be as an aid to configuration.

Markers (as do domains) create a second dimension 
for filtering. The TRACE marker in the logback-demo might be of interest.


-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch


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

Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)

[Curt Arnold <ca...@apache.org>]

My understanding of the motivation of "markers" is to provide a  
mechanism to provide explicit context (for example, IP address of  
current request) for a logging call which supplements the implicit  
context extracted from the current thread (contents of MDC and NDC,  
thread name, call stack).  The primary use for the explicit context  
is likely to provide information to be recorded in the log with a  
secondary use to provide information to be used by filters.

The motivation of logging domains appears to be to identify concerns  
that cut across the established hierarchy and the expected use  
appears to be as an aid to configuration.



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

Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)

[Ceki Gülcü <ce...@qos.ch>]

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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)

[Paul Smith <ps...@aconex.com>]

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