On Thu, Jan 23, 2014 at 10:18 PM, Ralph Goers
<[email protected]>wrote:
Gary, although Remko hasn’t said it I think he is implying that
he is
vetoing the code commit. Unfortunately, unless you can convince
Remko
otherwise you are going to have to revert the commit.
Remko, if that isn’t your intention then please say so as it will
save
Gary a bunch of work.
Hello, hello,
Wow, what a pickle of religious debate this has turned into!
Before I do indeed do more work:
Ralph
On Jan 23, 2014, at 6:34 PM, Remko Popma <[email protected]>
wrote:
I wish you had a story of some kind to show why you are so strongly
opposed to the new levels. I just wonder then why you are not
arguing for
fewer levels? Is 6 levels just the perfect number in your mind? If
you
designed a new logging system right now in a clean room approach,
what
would you devise?
FWIW, I do consider Log4j2 a brand new system, granting us the
freedom to
break APIs with version 1, which we've obviously done, but not in a
way
that will make it too difficult to port client code. For custom
appenders,
I've not tried to port my version 1 appenders yet...
To clarify my position on the proposed DIAG, VERBOSE, NOTICE log
levels:
I don't think these levels should be added to the Log4J API.
Here is my thinking:
1. The current five levels are a de facto. standard. (For example,
they
match the SLF4J levels.)
But they do not match JUL, which is more of a standard since it is
in
the
JRE; albeit a _brain-dead_ standard; no DEBUG level JUL? Really?
So clearly we care about certain kinds of standard but not others.
Since the Slf4j author created Log4j1, I would not expect otherwise
and
it
should not make it the best solution moving forward by default.
They are sufficient for the vast majority of log4j users. We should
be
hesitant to change this. My position would be to not change this
unless
we
all think this is a really good idea. (The bar should be high for
this
change.)
What are you afraid of? Confusing developers and users with 3 new
levels?
Let's give them more credit than that! ;)
2. From a practical point of view, making. levels an Extensible
Enum
provides a more powerful alternative solution, making the proposed
levels
unnecessary.
3. From an engineering/aestical POV, I feel the proposed levels are
arbitrary and the Extensible Enum solution is more elegant.
AGAIN, there are different features, why are they mutually
exclusive?
4. The proposed levels are not only unnecessary, I think they are
actually detrimental (for lack of a better word. I mean, not having
them
would be better).
The discussion in the "Web Issues, Logging Levels, and GA" thread
shows
how much opinions can differ about naming, strength, and intended
usage,
*even in our small group*. How can we predict what levels other
users
may
want?
How about using your own experience as a guideline? How have the
current
levels confused your users? Would fewer levels been better for them?
I've creating a logging system before Log4j1 existed, ported our
server
to
Log4j1 and then extended Log4j1 for our servers and tools at work.
Believe
you me, if I've taken the time to write the code, I will use it in
our
apps
instead of the inconsistent various workarounds that have propagated
in
our
code base. These are not "oh, these would be nice to have in
theory",
theses are "I know I can change my code now to use the new levels".
Granted, I am an advanced user. But like any system, I started using
a
few
features and then more and more.
We do use TRACE for some method entry and exit. And we use DEBUG a
lot.
But we need a level, among other things, for wire level hex dumps in
all
the different parts of the systems where many loggers are used. A
level
between TRACE and DEBUG would be a perfect solution. I and others
have
made
a good case for the NOTICE level as well, which some wanted as
CONFIG.
I see the new levels as a refinement based on experience.
Is this now a religious debate in which there is 0 chance of
convincing
you? Or is there 1 chance?
The proposed levels can easily confuse users or get in the way of
users
wanting to use these names at different strengths or with a
different
intended usage.
Whaaat? How can you presume to know users like that? Give people
more
credit than that, we are talking about programmers here. For our end
users,
our support folks tell them "Set the level to X and run the program,
then
send us the log" where they use a GUI to generate log config files.
Our
consultants (some are programmers) that go onsite, know the software
and
what the levels mean. They and the users will be ecstatic if I say
that
the
giant logs given by DEBUG will be smaller because all the hex dumps
will
be
at the VERBOSE levels. The TRACE level is for developers debugging
very
low
level code. FWIW, we had started to use different loggers for hex
dumps
but
this was hard to enforce and harder to configure, so no more of
that.
So before I revert anything please answer these questions and try to
convince _me_ :)
Alternatively, feel free to reply with "I VETO this commit" and will
revert the commit.
Thank you kindly for considering these opinions,
Gary
The fact that changes for these levels have already been committed
is
IMHO not an argument in its favor. On the contrary, I was surprised
at
the
timing of this commit: it was clear that many people were opposed
to
this
approach. To me it was also clear that we had started exploring
extensible
enums as a mechanism that would allow us to *avoid* adding
pre-defined
levels.
To repeat my position: I don't think these levels should be added
to the
Log4J API.
Remko
On Friday, January 24, 2014, Remko Popma <[email protected]>
wrote:
I'm fine with Nick's proposal to have two separate votes.
Remko
On Friday, January 24, 2014, Nick Williams <
[email protected]> wrote:
There has obviously been some serious discussion about these
topics.
We're not going to come to a total agreement on this. I propose:
- We have a committers-only vote in the "Enums and Custom Levels"
thread on whether to make Level an extensible enum.
- AFTER having that vote, we have a committers-only vote in this
thread
on whether to add these three levels.
- We only roll back this revision AFTER the second vote is
complete
and
IF the vote rejects the new levels.
Nick
On Jan 23, 2014, at 7:58 AM, Paul Benedict wrote:
On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy
<[email protected]>wrote:
We don't need to scuttle the new levels to support extensible
levels.
Of course. The two things are not technically related. That's not
what
this is about, though. Since there are camps for and against the
new
levels, I was hoping the "extensible enum" feature would bring
about a
compromise.
Gary's change is essentially a 'usability enhancement' - if
anything
close to 80% of the folks who might want custom levels can use
new
built-in levels, that's an API win in my book. Custom levels
help
the
other 20%, and I'm supportive of that.
Also please keep in mind this doesn't really add to our
maintenance
burden, which I think may be contributing to the concern about
adding
new levels. Gary already did the heavy lifting, and the change
to
something other than an enum for levels would just be a bit more
work
because of this addition.
Scott
On 1/23/14, Paul Benedict <[email protected]> wrote:
Let's not lose sight why the "extensible enum" discussion
occurred.
Speaking solely for myself, I am not fond of the new logging
levels;
but I
don't want the framework from preventing them. The intention
behind
this
proposal was to get agreement by scuttling the new levels but
allowing
anyone to add them in their own private code.
Paul
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second
Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
