Hi, there is no doubt that the proposal is cool. Can we discuss this in a fresh
separate thread?
Gary
-------- Original message --------
From: Paul Benedict <pbened...@apache.org>
Date:01/22/2014 20:52 (GMT-05:00)
To: Log4J Developers List <log4j-dev@logging.apache.org>
Subject: Re: Web Issues, Logging Levels, and GA
Agreed. This is not an engineering per se, but really more about if the feature
set makes sense.
Well if you guys ever look into the interface idea, you'll give log4j the
feature of getting enums to represent custom levels. That's pretty cool, IMO. I
don't know if any other logging framework has that and that would probably get
some positive attention. It shouldn't be so hard to do a find+replace on the
code that accepts Level and replace it with another name. Yes, there will be
some minor refactoring that goes with it, but hard? It shouldn't be.
A name I propose for the interface is LevelDefinition.
Paul
On Wed, Jan 22, 2014 at 6:48 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
Hi, I do not see this as an engineering problem but more a feature set
definition issue. So while there may be lots of more or less internally
complicated ways of solving this with interfaces, makers and whatnots, the
built in levels are the most user friendly.
I have have lots of buttons, knobs and settings on my sound system that I do
not use, just like I do not use all the methods in all the classes in the JRE...
Gary
-------- Original message --------
From: Remko Popma
Date:01/22/2014 18:38 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
Looks like we're in a tricky spot...
I count four people in favor of keeping the current levels who don't want to
add levels (Paul, Christian, Matt and myself),
two people who really want to add levels (Gary and Nick)
and two people who are not pushing for new levels but don't mind the change
(Scott and Ralph).
I don't think of adding new levels as a compromise, as it would only satisfy a
few of us.
Can we try finding a way that would satisfy all parties?
Why don't we think a little more about finding some mechanism that allows users
to add custom levels that are *as easy or nearly as easy to use as the
pre-defined levels*?
That mechanism can be anything (markers, extensible enum, an interface,
something else?), I am open to ideas.
This is an engineering problem, let's use our engineering skills (instead of
our debate skills :-).)
Let's think about this more, with open minds, before rushing into a solution
that many have reservations about.
On Thu, Jan 23, 2014 at 6:07 AM, Paul Benedict <pbened...@apache.org> wrote:
Yes, I know. It is a big change but it is also one that's necessary to support
custom logging levels that are enums.
On Wed, Jan 22, 2014 at 3:04 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
Paul,
Take a look at the Logger, LoggerConfig and Lo4jLogEvent classes and LogEvent
interface in log4j-core. Then look at the Filter interface and the
ThresholdFilter implementation. Looking at those classes you will see that the
change you are proposing has a much larger impact than what you are thinking.
Since the custom levels would not be part of the enum all the code would have
to be changed to use the new Interface you are proposing, not the Level enum.
Ralph
On Jan 22, 2014, at 12:37 PM, Paul Benedict <pbened...@apache.org> wrote:
Ralph,
Perhaps you're misunderstanding or I was unclear (let's say it's the latter).
The interface is only so you can allow custom log levels as an enum. The client
code could still use the enums you provided today. All that's changing is the
API signatures to accept the interface -- which conveniently all the enums
would implement. As I said, FATAL/ERROR/INFO/WARN/DEBUG/TRACE would implement
the interface.
It's worth considering this because I think we're about to pollute log4j with
logging levels that really don't belong in the public api. These are definitely
custom things people should implement themselves.
Paul
On Wed, Jan 22, 2014 at 12:33 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
First, I assume you meant to code “implements LogLevelStrength” instead of
“extends LogLevelStrength” since an enum already implicitly extends Enum and a
Class (or Enum) can’t extend an Interface.
Second, doing this would mean that the Log4j 2 core would have to be modified
to never use the Level enum and only use the Interface, except perhaps in
ThresholdFilter which can really only be configured with one of the Level enum
values. Not being able to use Level as a method parameter and field in the
LogEvent makes its value as an enum minimal. Only being able to use Level
values in the ThresholdFilter means anyone with a custom Level has to write
their own custom Level Filter.
I think providing the extra levels is a fair compromise.
Ralph
On Jan 21, 2014, at 8:50 AM, Paul Benedict <pbened...@apache.org> wrote:
Or if you really want to get fancy (!!!), don't make the log4j API accept an
Level, but an interface that each logging level Enum object implements. Then
programmers can use enums. Example:
public interface LogLevelStrength {
int getStrength();
}
public enum Level extends LogLevelStrength {
FATAL() {
public int getStrength() { return 600; }
}
...
}
public enum MyCustomLevel extends LogLevelStrength {
DIAGNOSTIC() {
public int getStrength() { return 250; }
}
...
}
On Tue, Jan 21, 2014 at 10:45 AM, Paul Benedict <pbened...@apache.org> wrote:
It won't be possible with an enum, yes, but we should have a way to allow
extensions. For example, if we publically document the integer level of the
enums (separated by 100), then we can provide an overload that accepts an
integer. That's how you can allow people to slide in their extensions.
Philospohy: enums for the standard, ints for the custom programmer.
Paul
On Tue, Jan 21, 2014 at 10:42 AM, Gary Gregory <garydgreg...@gmail.com> wrote:
On Tue, Jan 21, 2014 at 11:33 AM, Paul Benedict <pbened...@apache.org> wrote:
On Tue, Jan 21, 2014 at 10:25 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
I tend to agree that there is ambiguity between TRACE and VERBOSE, but I have
no problem adding it if it means end users will have more flexibility with
little cost.
I think this is meaningless flexibility. It smells of adding a feature without
a good reason. Imagine the conversations people will have to explain the
difference between TRACE and VERBOSE. I can't think of any good universal
justification for its use that demands an addition to log4j.
If you do not like it, do not use it ;)
This is best reserved for a personal extension.
Which is not possible since Level is an enum, hence this discussion before the
API freezes.
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
Cheers,
Paul
--
Cheers,
Paul
--
Cheers,
Paul
--
Cheers,
Paul
--
Cheers,
Paul
