Mailing-List: contact log4net-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4NET User" <log4net-user@logging.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <A9E593F7-C072-4BC8-98A6-F63CE5EB571D@apache.org>
From: Curt Arnold <carnold@apache.org>
To: "Log4NET User" <log4net-user@logging.apache.org>
In-Reply-To: <6D5D330634363B43A0F8B9DB978CD42B039422E9@SV-EXCH.hlit.local>
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: The current target framework (Microsoft .NET Framework 3.5) is
 not supported by log4net
Date: Thu, 7 Feb 2008 18:04:31 -0600
References: <513292.20546.qm@web30501.mail.mud.yahoo.com>
 <02f901c86973$810d7f00$08faa8c0@grassoc.co.uk>
 <6D5D330634363B43A0F8B9DB978CD42B03942242@SV-EXCH.hlit.local>
 <2480e6b30802071214i10ce6661sdc5134917912b0dc@mail.gmail.com>
 <6D5D330634363B43A0F8B9DB978CD42B039422E9@SV-EXCH.hlit.local>


On Feb 7, 2008, at 3:38 PM, Mike Baker wrote:

> The reason for getting into the source is we are interested in =20
> changing the way log filtering is done.  Rather than having levels =20
> of fatal, error, info, warn, debug, etc., which are hierarchically =20
> enabled (i.e., if you set the level for debug, you get all the =20
> rest), we would like to be able to selectively enable different =20
> logging by log category/type, for example:
> LOG_FATAL:  Reserved for module-fatal unrecoverable conditions, =20
> indicating the module cannot continue normal operations.  Normally =20
> never filtered.
> LOG_ERROR:  Reserved for module errors which are recoverable.  =20
> Normally never filtered.
> LOG_STATUS:  Catch-all, used to report status / information.
> LOG_CONFIG:  Used to report configuration change activities.
> LOG_FUNC:  Used to report entry / exit from functions.
> LOG_TIMING:  Used to report performance, i.e., the module has =20
> reached an observable event.
> LOG_COMM:  Used to report the module is attempting / has completed =20
> intermodule communications.
> LOG_DBA:  Used to report database activities.
> LOG_USER08=85LOG_USER31:  TBD usage, perhaps to accomplish special =20
> debug logging / filtering for troubleshooting a system problem.
>
> We would like these log messages from these various categories/types =20=

> to be enabled / disabled independently.  For example, if we are =20
> trying to optimize performance, we might only turn on LOG_TIMING to =20=

> try identify what is running slow.  Profiling helps on this, but if =20=

> a call varies significantly in how long it takes depending upon the =20=

> parameters passed, logging will help us focus on the problem.
>
> In a previous company that I worked, there was a C++ logging library =20=

> that supported both logging priority (hi, med, low =96 analogous to =20=

> log4net=92s fatal, error, etc.), but also included logging category, =20=

> like described above.  We found was that logging category was quite =20=

> useful in actual debugging, and having the logging priority, even =20
> though there were 3 levels, we essentially used them more like =20
> boolean flags.
>
> Has anyone else considered something similar to what I described =20
> above for log4net?
>
> Thanks,
> -Mike


It is a pretty common temptation to want to use levels to indicate =20
topic or audience which is precisely what the logger name hierarchy =20
(which was originally called category in log4j, but was renamed as =20
logger to be consistent with JDK 1.4's logging)  is intended to do.  =20
Most new users wrongly assume that logger names MUST mirror class =20
names.  That is one useful pattern, but not the only pattern for =20
organizing your logging messages,

If you attempt to use level to indicate topic, then you come up with =20
the dilemma on how to prioritize highly significant TIMING or COM or =20
DBA messages from less significant messages.

I would suggest that you use logger names like:

"com.example.myapp.myclass" for generic diagnostic logging
"dba.com.example.myapp.myclass" for database relative logging in that =20=

specific class.
"comm.com.example.myapp.myclass" for communication relative logging in =20=

that specific class.
"timing.com.example.myapp.myclass" for timing relative logging in that =20=

specific class.

You could flip the order if the class is a more significant than =20
function for filtering or routing.