You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Paul Smith <ps...@aconex.com> on 2007/03/29 08:34:52 UTC
Logging Domains committed to sandbox (dodgy cvs spam email address though)
I just committed Revision 523581 to the logging/sandbox, but I got an
email bounce saying:
<sa...@logging.apache.org>:
Sorry, no mailbox here by that name. (#5.1.1)
Anyway, the SVN URL to the project (with Eclipse .project settings..)
is here:
http://svn.apache.org/repos/asf/logging/sandbox/LoggingDomains/
Would certainly like some comments.
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: psmith@aconex.com www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.
Re: Logging Domains committed to sandbox (dodgy cvs spam email
address though)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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
Re: Logging Domains committed to sandbox (dodgy cvs spam email
address though)
Posted by 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)
Posted by Paul Smith <ps...@aconex.com>.
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.
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).
Paul
Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)
Posted by Jacob Kjome <ho...@visi.com>.
Hi Paul,
Are logging domains akin to Markers in the SLF4J/Logback world?
Jake
Quoting Paul Smith <ps...@aconex.com>:
> I just committed Revision 523581 to the logging/sandbox, but I got an
> email bounce saying:
>
> <sa...@logging.apache.org>:
> Sorry, no mailbox here by that name. (#5.1.1)
>
> Anyway, the SVN URL to the project (with Eclipse .project settings..)
> is here:
>
> http://svn.apache.org/repos/asf/logging/sandbox/LoggingDomains/
>
> Would certainly like some comments.
>
> Paul Smith
> Core Engineering Manager
>
> Aconex
> The easy way to save time and money on your project
>
> 696 Bourke Street, Melbourne,
> VIC 3000, Australia
> Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
> Email: psmith@aconex.com www.aconex.com
>
> This email and any attachments are intended solely for the addressee.
> The contents may be privileged, confidential and/or subject to
> copyright or other applicable law. No confidentiality or privilege is
> lost by an erroneous transmission. If you have received this e-mail
> in error, please let us know by reply e-mail and delete or destroy
> this mail and all copies. If you are not the intended recipient of
> this message you must not disseminate, copy or take any action in
> reliance on it. The sender takes no responsibility for the effect of
> this message upon the recipient's computer system.
>
>
>
>
---------------------------------------------------------------------
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)
Posted by Paul Smith <ps...@aconex.com>.
>
> Could you add the standard Apache Source Header to the files, plus
> add the LICENSE and NOTICE? That should be done by the original
> contributor.
>
Totally forgot about that, thanks for the reminder.
> I think that org.apache.logging.domain would be preferable to
> org.apache.loggingdomain. I had thought about using
> org.apache.logging as a base package for non-log4j specific Java
> code.
>
An easy change.
> I've got to find some time to get my feet wet with JMX.
With Java 5, JMX is lovely. I couldn't live without JMX (although
whoever wrote JConsole needs to sit down with a usability expert).
Paul
Re: Logging Domains committed to sandbox (dodgy cvs spam email address though)
Posted by Curt Arnold <ca...@apache.org>.
On Mar 29, 2007, at 1:34 AM, Paul Smith wrote:
> I just committed Revision 523581 to the logging/sandbox, but I got
> an email bounce saying:
>
> <sa...@logging.apache.org>:
> Sorry, no mailbox here by that name. (#5.1.1)
>
> Anyway, the SVN URL to the project (with Eclipse .project
> settings..) is here:
>
> http://svn.apache.org/repos/asf/logging/sandbox/LoggingDomains/
>
> Would certainly like some comments.
>
I've tweaked the asf-mailer.conf and hopefully all modifications
under logging/sandbox will go to log4j-cvs@logging.apache.org now.
Could you add the standard Apache Source Header to the files, plus
add the LICENSE and NOTICE? That should be done by the original
contributor.
I think that org.apache.logging.domain would be preferable to
org.apache.loggingdomain. I had thought about using
org.apache.logging as a base package for non-log4j specific Java code.
I've got to find some time to get my feet wet with JMX.