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 bu...@apache.org on 2009/03/31 11:49:25 UTC
DO NOT REPLY [Bug 46941] New: Sub Level Logging Technique
https://issues.apache.org/bugzilla/show_bug.cgi?id=46941
Summary: Sub Level Logging Technique
Product: Log4j
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Other
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: roger77_lb@hotmail.com
While improving code for a logger at hand I found it useful to define my own
levels to be suited to every application I have. That is, different logging
levels defined for different applications.
Moreover, I needed to be able to log a certain type of events no matter what
the chosen level was (see logger.transparentLevels below).
At the beginning, I created a new config parameter as:
logger.referenceDescendingLevels=err,inf,deb
which means that err (error) > inf (information) > deb (debug)
which is practically the same story as Apache Log4J' Basic Selection Rule.
To be able to log CDR (Call Detail Records) type events, I have created a new
config parameter as:
logger.transparentLevels=cdr
(we can add / modify / displace levels in both parameters according to our
needs)
The name 'transparent' was chosen to indicate that the levels listed in
logger.transparentLevels are transparent to the Selection Rule ! A request with
a level listed here passes the Selection Rule no matter what other application
logging settings are.
Till now, we have defined a Reference list and a Transparent List of levels, we
just need one thing, a chosen log level which will define the current logging
settings of our application:
logger.chosenLogLevel=inf.5
For the currently defined reference logging levels, values could be as listed
below:
err (same as err.0)
inf (same as inf.0)
deb (same as deb.0)
err.2 (any number)
inf.3 (any number)
deb.8 (any number)
I will explain what is the .5 for (in the logger.chosenLogLevel config) below:
The next interesting feature I've added is to be able to use Sub Levels into
each level in an arbitrary fashion using a simple approach: the numbering
system !
logger.chosenLogLevel=deb.4 means:
log all log requests (Logger.Log("deb.4", "This is your log request");) till
level deb and sub level 4
Examples:
1. a request with deb.10 will be ignored.
2. a request with deb.3 / deb.2 / deb.1 / deb / inf / inf.2 / inf.10000,
etc. / err.4, etc. / err will certainly be served.
Note that the technique illustrated here can be used in a way to enable
debugging for an application deployed on a live server, and be able to do
further debugging (for instance, by specifying logger.chosenLogLevel=deb.7)
when a problem is to be debugged. Of course, software developers are required
to include adequate logging requests wherever useful it might be.
Of course, software developers are invited to plan their logging software
architecture so that they define which 'things' are to be considered at which
'level', 'sub level'; and code their sub levels in the most appropriate way,
such as to use 'sub level' numbers in a meaningful way.
For this purpose, I propose to use SubLevel classes where useful sub levels are
defined as:
public static int sub_level_live = 0;
public static int sub_level_deb = 0;
public static int sub_level_deb_transactions_summary = 1;
public static int sub_level_deb_transactions_full = 2;
public static int sub_level_deb_show_low_level_handshaking = 3;
Those sub levels definitions should be suitable for your application logic.
Can this be implemented in Log4J ? If it already can be done, how is that ? Can
you provide a clear example please ?
If not, what about adding it to Log4J's TODO list ?
Best Regards,
Roger Tannous
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 46941] Sub Level Logging Technique
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46941
--- Comment #2 from Curt Arnold <ca...@apache.org> 2009-04-02 19:28:08 PST ---
This really seems like you are trying to use levels to accomplish what the
logger hierarchy was designed to do. Many people make the assumption that
since a common pattern for logger names is to follow class names that is the
only way they can be used. Logger names are, in general, are "topics" and you
can use any system that works to give you the type of control that you'd want.
If you are trying to assign a "topic" (network, database, etc) to a level, then
you not messing up the "topic" or "audience" concept up with the "severity"
concept. Logger names are really flexible and you can likely accomplish you
goals without nearly as many complications.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 46941] Sub Level Logging Technique
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46941
--- Comment #4 from Roger Tannous <ro...@hotmail.com> 2009-04-03 02:57:42 PST ---
(In reply to comment #2)
> This really seems like you are trying to use levels to accomplish what the
> logger hierarchy was designed to do. Many people make the assumption that
> since a common pattern for logger names is to follow class names that is the
> only way they can be used. Logger names are, in general, are "topics" and you
> can use any system that works to give you the type of control that you'd want.
>
> If you are trying to assign a "topic" (network, database, etc) to a level, then
> you not messing up the "topic" or "audience" concept up with the "severity"
> concept. Logger names are really flexible and you can likely accomplish you
> goals without nearly as many complications.
Using sub-levels is quite different from the standard logger hierarchy in that
a new sub level can be introduced without being defined (because it's already a
numeric value !)
For example, if we have already defined our logging by:
logger.referenceDescendingLevels=a,b,(c,d),e,f
We can use in the code:
Logger.Log("e.11", "log text here");
without having to define sub-level 11 for logging level 'e' anywhere.
(<start_of_parenthesis>
I'm using here a direct String value as: "e.11", but in reality, you can have a
class where levels are defined like:
public static String LOG_LEVEL_DATABASE_CONNECTION = "e";
public static String LOG_LEVEL_DATABASE_QUERY = "f";
then use:
Logger.Log(LOG_LEVEL_DATABASE_CONNECTION + ".11", "DB connection logging
here");
// Remember, I call this Logger.Log(...); function call a " log request " or a
" logging request "; you'll find this name in the text below.
<end_of_parenthesis>
)
Additionally, suppose you have defined your levels and your application is up
and running, then after a certain time you need a new logging "level" and need
to separate its logging from the rest of the 'logs'; without the proposed
technique, you have to 'insert' your new level _in_between_ existing ones.
Doesn't this mean that you have to do additional work as you'll have to modify
all " logging requests " that are usually "below" the newly introduced one ?
At the contrary, using the proposed technique, all you have to do is add the "
logging requests " and add your new entry ANYWHERE in the
logger.referenceDescendingLevels like:
logger.referenceDescendingLevels=a,b,MY_NEW_LEVEL,(c,d),e,f
Now within MY_NEW_LEVEL, you can use as many sub-levels as you need without
having to define them here.
Finally, in the proposed technique, the method does not oblige you to abide by
a certain rule as how to design levels and sub-levels. Most importantly, it
doesn't tell sub-levels are strictly to be considered as severity ! This can be
regarded as your own application design issue.
You can use sub-levels for one application as a severity indicator; for others
as a sub-category, or even as a dummy number that you plan to deny logging for
later after you test your new feature set.
Remember that we can do this:
logger.referenceDescendingLevels=a,b,MY_NEW_LEVEL,MY_NEW_LEVEL.1,MY_NEW_LEVEL.2,(c,d),e,f
Here is an example scenario:
Suppose MY_NEW_LEVEL is newly introduced so we can do:
logger.referenceDescendingLevels=a,b,MY_NEW_LEVEL,(c,d),e,f
supposing:
logger.chosenLogLevel=e
and the following " logging requests " are all allowed:
Logger.Log(MY_NEW_LEVEL, "your log text here");
Logger.Log(MY_NEW_LEVEL + ".0", "your log text here"); // same as first line
Logger.Log(MY_NEW_LEVEL + ".1", "your log text here");
Logger.Log(MY_NEW_LEVEL + ".2", "your log text here");
Logger.Log(MY_NEW_LEVEL + ".3", "your log text here");
You do your tests, then want to restrict logging beyond MY_NEW_LEVEL.2 for the
logging level MY_NEW_LEVEL. All you'll have to do is:
logger.referenceDescendingLevels=a,b,MY_NEW_LEVEL,MY_NEW_LEVEL.1,MY_NEW_LEVEL.2,(c,d),e,f
supposing:
logger.chosenLogLevel=e
As a result, the following " logging requests " are allowed:
Logger.Log(MY_NEW_LEVEL, "your log text here");
Logger.Log(MY_NEW_LEVEL + ".0", "your log text here"); // same as first line
Logger.Log(MY_NEW_LEVEL + ".1", "your log text here");
Logger.Log(MY_NEW_LEVEL + ".2", "your log text here");
But this one is not:
Logger.Log(MY_NEW_LEVEL + ".3", "your log text here");
For this example value, the following " logging requests " for an undefined
level is not allowed (i.e., they don't generate an error, but are simply not
logged):
Logger.Log("x", "your log text here");
Logger.Log("x.5", "your log text here");
The idea in the example is that " logging requests " with levels that are not
defined anywhere will not generate any error, they're simply ignored.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 46941] Sub Level Logging Technique
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46941
Roger Tannous <ro...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roger77_lb@hotmail.com
--- Comment #1 from Roger Tannous <ro...@hotmail.com> 2009-04-02 05:36:28 PST ---
(In reply to comment #0)
The 'requirement' is modified (improved) as described below:
logger.referenceDescendingLevels=err,general_info,(connection_status,handshaking),deb
As you can see, we can put sets of levels into parentheses to indicate that we
wish the 'grouped levels' to be considered in the same 'logical level'.
For the example above, connection_status and handshaking both belong to the
same 'logical level' 2 (levels are 0 based in my implementation).
Of course, we can include more than one group of parentheses like in the below:
logger.referenceDescendingLevels=a,(b,c,d),e,(f,g),h,i
LEVEL LOGICAL_LEVEL
a 0
b 1
c 1
d 1
e 2
f 3
g 3
h 4
i 5
Furthermore, we can include levels in "full format" into this config value, but
this has one drawback, continue reading...
logger.referenceDescendingLevels=a,b,(c,d),(e,e.1,e.2,e.3),e.4,e.5,f
Once e,e.1,e.2,e.3 are defined in 'logical level' 3, we are obliged to state
all other available levels belonging to the level named 'e' in "full format"
(currently: e.4 and e.5) to prevent them from being missed !
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 46941] Sub Level Logging Technique
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46941
--- Comment #3 from Ralph Goers <Ra...@dslextreme.com> 2009-04-02 22:20:35 PST ---
I would suggest that you take a look at the Marker support in SLF4J and Logback
and see if that would meet your needs. If so I would suggest asking for that
feature in a future release instead of sub levels.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org