On Jun 27, 2005, at 3:21 PM, Schuweiler, Joel J. wrote:
Knowing what server a log comes from isn't enough. I need to know
which application it's coming from.
This could simply be achieved by requiring everyone to put a
certain keyword into the log message and use the StringMatchFilter
or by using a custom filter which checks the category name/logger
name (what is the proper term for this??).
I'm pretty shocked that there isn't an easy way to do this already.
From the little I've been able to follow this thread, it looks like
you for some reason are reluctant to do it the easy way or are trying
to make the problem harder than it needs to be.
There are two "easy" ways to make decisions on a particular log
request: the logger and level of the log request. Those are the
preferred names of concepts in log4j and JDK 1.4. Earlier in the
development of log4j, those concepts were named "category" and
"priority" but where changed to be consistent with JDK 1.4 logging.
Topic and severity are also common synonyms for logger and level. To
recap:
logger (current, preferred) == category (early log4j) == topic (other
systems)
level (current, preferred) == priority (early log4j) == severity
(other systems)
The logger hierarchy is similar to a file system hierarchy. The name
of a logger indicates a relationship to other loggers like file
names, except that logger names use a "." instead of a "/" or "\" to
separate path elements. There is a special root logger (like / in a
file system) that all other loggers directly or indirectly descend from.
Making a decision based on the logger and level is like finding a
file using "ls" or "dir".
Filters are an additional mechanism to make decisions on log requests
when the primary means are not sufficient. Extending the file system
analogy, it would be like finding a file using "grep" or "Find in
Files". When designing a logging strategy, you'd like to design it
in such a way that you'd rarely have to use "grep", but could find
your file (or at least narrow the search) by the file hierarchy that
you've designed.
Like designing a file system layout, you'd want to define your logger
hierarchy to that the most significant aspect (at least in the most
common queries) comes first, the successively less significant
aspects. For example, if you'd think it would be more common that an
user would like to group all messages related to, for example,
security, than it would be to isolate all messages from a particular
application, then you would design your logger hierarchy something like
/
security
security.app1
security.app2
database
database.app1
database.app2
If it was more common to group all messages from one application
together, then your hierarchy would look like
/
app1
app1.security
app1.database
app2
app2.security
app2.database
Making decisions based on logger and level is also much more
efficient than making decisions based on content, just like "ls" is
faster than "grep". Decisions based on logger and level can occur
before the creation of a LoggingEvent, filter based decisions occur
much later.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
