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 2006/02/11 17:05:22 UTC
DO NOT REPLY [Bug 38617] New: - Support for custom levels without specifying classname
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
Summary: Support for custom levels without specifying classname
Product: Log4j
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Configurator
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: wfe.dehaan@gmail.com
Hereby I request that custom levels are supported without the need to specify
the classname.
Currently, the configurators allow the standard levels (such as INFO, ERROR and
FATAL) to be specified without specifying a class name. For example, in a
properties file:
log4j.rootLogger=DEBUG, console
However, custom levels are only supported if they are referred to by name and
classname, separated by a hash. For example:
log4j.rootLogger=NOTICE#com.company.log.LogLevel, console
I propose the following alternative is supported:
log4j.rootLogger=NOTICE, console
Currently, configurators use Level.toLevel(String,Level) class method to convert
the level string to a Level object. The current implementation (in 1.2.13) is as
follows:
public static Level toLevel(String sArg, Level defaultLevel) {
if(sArg == null)
return defaultLevel;
String s = sArg.toUpperCase();
if(s.equals("ALL")) return Level.ALL;
if(s.equals("DEBUG")) return Level.DEBUG;
if(s.equals("INFO")) return Level.INFO;
if(s.equals("WARN")) return Level.WARN;
if(s.equals("ERROR")) return Level.ERROR;
if(s.equals("FATAL")) return Level.FATAL;
if(s.equals("OFF")) return Level.OFF;
if(s.equals("TRACE")) return Level.TRACE;
return defaultLevel;
}
Proposed implementation scenario:
- use an internal Map to convert from String to Level, in the Level class
- add an entry to this Map each time a Level instance is constructed, with the
appropriate name as the key and the object as the value
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
------- Additional Comments From wfe.dehaan@gmail.com 2006-02-11 17:12 -------
Of course I should have said "Hashtable" instead of "Map", since the code needs
to be compatible with JDK 1.1.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
------- Additional Comments From wfe.dehaan@gmail.com 2006-02-14 20:13 -------
(In reply to comment #6)
> Okay, I missed that you were expecting the caller to have registered "NOTICE"
by creating a derived
> class prior to calling the configurator and misread the casts of the
Priority.INFO et al which led me to
> think you might have been working on code where Priority extends Level instead
of vice-versa.
Perhaps I should have been clearer on what my intensions were.
> I'm concerned that the lazy initialization of the hashtable might present a
threading issue. It also
The lazy initialization is indeed a bit ugly. I'll see if I can fix that. And
indeed it may present a threading issue. I didn't think of that yet.
> continues to perpetuate the subclassing Level just to work around the
protected constructor. I also
How is the fact that Log4J requires subclassing Level relevant? I don't intend
to change that fact here, it's just a relatively minor improvement.
> don't like joining the construction and registration actions (though I
understand why those were done).
They could be separated. But then you lose some of the perceived elegance from
the perspective of the Log4J user...
> The NAME#classname is a bit ugly, but it does not require registration of the
level prior to the
> configuration and it only uglifies the configuration file and the benefit of
the patch doesn't seem to be
> sufficient to justify the potential ramifications (particularly in the 1.2.x
branch) in my opinion.
I disagree, because I have a practical issue here. The issue is that I don't
want to specify a class name in my Log4J settings, since the latter are
maintained by the IT Operations department. And class names are not in their
vocabulary.
Also, we provide them with documentation on log levels, but then one log level
is suddenly configured differently from all the others. That's inconsistent.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
genman@noderunner.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From genman@noderunner.net 2007-01-28 04:07 -------
Really the purpose of the patch is to make editing your log4j configuration
files (with your custom levels) easier for your IT team. This is not a general
concern.
One big problem with having them created dynamically would be introducing memory
leaks. The other is compatibility. I.e. how do levels "leave" the system?
I'm guessing this will never "fly" with the log4j team. So I suggest that you
approach this in another way. Make a patch that improves the DOM or .properties
configuration format so that levels can be registered at the top. Then, when
parsing, the levels can be referenced using a simple name.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
carnold@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
------- Additional Comments From carnold@apache.org 2006-02-11 21:53 -------
I don't see any mechanism that assigns a numerical level value an unrecognized level. How would log4j
know whether NOTICE where more or less significant than "ERROR", for example. In the current (less than
optimal) mechanism, that infomation is coded into the class.
The patch seems to predate the restoration of Level extending Priority that occurred to bring log4j 1.3
back into line with log4j 1.2.
I definitely agree the current level extension mechanism is not ideal. I've thought about extending log4j
to recognize arbitary integer values for levels, so if you wanted 9999 levels between DEBUG and INFO you
could have them without any custom code, though the level names might be DEBUG+5000.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
------- Additional Comments From carnold@apache.org 2006-02-14 18:30 -------
Okay, I missed that you were expecting the caller to have registered "NOTICE" by creating a derived
class prior to calling the configurator and misread the casts of the Priority.INFO et al which led me to
think you might have been working on code where Priority extends Level instead of vice-versa.
I'm concerned that the lazy initialization of the hashtable might present a threading issue. It also
continues to perpetuate the subclassing Level just to work around the protected constructor. I also
don't like joining the construction and registration actions (though I understand why those were done).
The NAME#classname is a bit ugly, but it does not require registration of the level prior to the
configuration and it only uglifies the configuration file and the benefit of the patch doesn't seem to be
sufficient to justify the potential ramifications (particularly in the 1.2.x branch) in my opinion.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
------- Additional Comments From wfe.dehaan@gmail.com 2006-02-11 18:04 -------
Created an attachment (id=17658)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=17658&action=view)
Patch that makes Level dynamically store and lookup Level instances by name
Attached is a patch that implements the change I propose. I've executed all
unit tests successfully with it.
Note that there are the following side-effects:
1) there will be a warning logged if a duplicate Level instance is created.
2) Priority.INFO is now equal to Level.INFO. Same applies to the other fields
in Priority.
Personally, I see no harm in these side-effects.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
wfe.dehaan@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #17661|0 |1
is obsolete| |
------- Additional Comments From wfe.dehaan@gmail.com 2006-02-14 20:36 -------
Created an attachment (id=17692)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=17692&action=view)
Patch that makes Level dynamically store and lookup Level instances by name,
with test case
I've improvement the patch. This time, the Hashtable is initialized by the
class initializer. However, I moved the ALL_LEVELS class field to class
Priority for this, because the latter is initialized before class Level, but it
constructs Level instances. So the Level constructor gets called before the
class initializer. This was the initial reason I introduced lazy
initialization.
Also, I've extended the test case to test some more situations.
I will think about registering levels explicitly. Perhaps I'll submit another
version of the patch for that.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
------- Additional Comments From wfe.dehaan@gmail.com 2006-02-14 17:16 -------
(In reply to comment #4)
> I don't see any mechanism that assigns a numerical level value an unrecognized
level. How would log4j
> know whether NOTICE where more or less significant than "ERROR", for example.
In the current (less than
> optimal) mechanism, that infomation is coded into the class.
I don't understand. How is this related to the issue I fix? It does not touch
the basic properties of a Level (or a Priority instance, for that matter). So
everything else remains working as it does now. Just create a Level instance as
one would do now. Then you already specify the numerical level.
I think you think I'm trying to solve a larger (or even different) issue.
The requested enhancement is not about not having to do any coding. You still
have to write some code that will construct a Level instance with a proper name,
numeric value and syslog-equivalent value.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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 38617] - Support for custom levels without specifying classname
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38617>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38617
wfe.dehaan@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #17658|0 |1
is obsolete| |
------- Additional Comments From wfe.dehaan@gmail.com 2006-02-11 19:51 -------
Created an attachment (id=17661)
--> (http://issues.apache.org/bugzilla/attachment.cgi?id=17661&action=view)
Patch that makes Level dynamically store and lookup Level instances by name,
with test case
I've attached a new patch, this time with a unit test.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org