Okay, I finally got a minute to read all of these emails, and...
EVERYBODY FREEZE!
What if I could get you an extensible enum that required no interface changes
and no binary-incompatible changes at all? Sound too good to be true? I
proposed this months ago (LOG4J2-41) and it got shot down mult
I would be happy with any solution that is generic enough to fulfill all
users requirements and does not involve adding ad hoc levels.
On Thursday, January 23, 2014, Nick Williams
wrote:
> Okay, I finally got a minute to read all of these emails, and...
>
> EVERYBODY FREEZE!
>
> What if I could
Gary,
Would you mind rolling back the changes you made in revision 1560602 (and
perhaps r1560356)?
This change added DIAG, VERBOSE, NOTICE log levels to many files.
I don't think we all agreed on that approach and we have some promising
ideas for an alternative solution that should satisfy everyon
Thank you.
On Thu, Jan 23, 2014 at 1:24 AM, Benedikt Ritter wrote:
> You can use themail archives:
> http://mail-archives.apache.org/mod_mbox/logging-log4j-user/
>
>
> 2014/1/22 Saibabu Vallurupalli
>
>> Hi Team,
>>
>> I need to attach this conversation to my JIRA ticket and I am using my
>>
Maybe:
ZOMBIE_APOCALYPSE > APOCALYPSE > CATASTROPHE > EMERGENCY > FATAL > ...
On 23 Jan 2014, at 3:56, Gary Gregory wrote:
But that is not as high as APOCALYPSE right?
Gary
Original message
From: Matt Sicker
Date:01/22/2014 21:43 (GMT-05:00)
To: Log4J Developers List
Su
I pretty much like this Nick
I read the question from time to time how one can add custom log levels
in log4j,
so this is surely a useful feature for some.
On 23 Jan 2014, at 10:02, Remko Popma wrote:
I would be happy with any solution that is generic enough to fulfill
all
users requirement
Yes yes now we are getting somwhere... UNICORN_AND_RAINBOWS!
G
Original message
From: Christian Grobmeier
Date:01/23/2014 06:31 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
Maybe:
ZOMBIE_APOCALYPSE > APOCALYPSE > CATASTROPHE > E
Neat idea. I'd update it for proper concurrency, though. I could write a mock
version of this to show what I mean.
Matt Sicker
> On Jan 23, 2014, at 2:42, Nick Williams wrote:
>
> Okay, I finally got a minute to read all of these emails, and...
>
> EVERYBODY FREEZE!
>
> What if I could get y
It's a neat idea but it's not a Java enum. I think one of Ralph's goal was
to allow client code to use enums. I still think we should continue that
path. At any rate, this will hopefully lead to a synthesis of ideas and
agreement.
On Thu, Jan 23, 2014 at 8:22 AM, Matt Sicker wrote:
> Neat idea.
I’m more in favor of this than what you had proposed. To be honest, with what
you proposed I don’t see much value left in keeping the Level enum.
Yes, I prefer using the enum (obviously, or I wouldn’t have implemented it that
way), but if the consensus is to change it to a class, so be it.
As f
Remko, are you saying that if we make the changes proposed in the other thread
that we should not add any of these levels to the new Level class?
Ralph
On Jan 23, 2014, at 1:22 AM, Remko Popma wrote:
> Gary,
>
> Would you mind rolling back the changes you made in revision 1560602 (and
> pe
I don't think the two have to be mutually exclusive - we can enhance
'custom level' support via a new mechanism and add built-in support
for the new levels as well.
I personally don't think they're confusing, as folks have mentioned,
httpd uses them.
I used to think of levels as 'severities', but
}
%d %p %C{1.} [%t] %m%n
{code}
With provided configuration, result files will be named as follows:
output.20140123-005437-1.log
output.20140123-005440-1.log
output.20140123-005444-1.log
output.20140123-005448-1.log
output.20140123
rter: Alexander Khokhlov
>
> With provided configuration, result files will be named as follows:
> output.20140123-005437-1.log
> output.20140123-005440-1.log
> output.20140123-005444-1.log
> output.20140123-005448-1.log
> output.20140123-005451-1.log
> instead of:
> output.2
gt;
>
>
> %d %p %C{1.} [%t] %m%n
>
>
> {code}
>Reporter: Alexander Khokhlov
>
> With provided configuration, result files will be named as follows:
> output.20140123-005437-1.log
> output.20140123-00544
Well said Scott.
These are two separate features.
Gary
Original message
From: Scott Deboy
Date:01/23/2014 11:49 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Levels added in revision 1560602
I don't think the two have to be mutually exclusive - we can enhance
'c
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 ad
We don't need to scuttle the new levels to support extensible levels.
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 su
On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy 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 "ex
A ZOMBIE_APOCALYPSE Level would be EPIC! ;-)
N
On Jan 23, 2014, at 1:31 AM, Christian Grobmeier wrote:
> Maybe:
>
> ZOMBIE_APOCALYPSE > APOCALYPSE > CATASTROPHE > EMERGENCY > FATAL > ...
>
> On 23 Jan 2014, at 3:56, Gary Gregory wrote:
>
>> But that is not as high as APOCALYPSE right?
>>
>>
ATOM QUARK STRING?
Original message
From: Nick Williams
Date:01/23/2014 13:44 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
A ZOMBIE_APOCALYPSE Level would be EPIC! ;-)
N
On Jan 23, 2014, at 1:31 AM, Christian Grobmeier 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 committe
By a generic definition, this new Level is certainly an enum. And it's written
in Java. No, it's not a Java-language official enum. But, as far as byte code
goes, it's nearly identical to an official enum. Users who don't need custom
levels will use it EXACTLY like they would use an enum. It's a
Hi Good morning.
I am trying to implement Rewrite Appender logic and based on my other
conversations I understood the way I am doing below, But still I am unable
to control certain messages.
My Policy class is:
***
@Override
public LoggingEvent rewrite(LoggingEvent source) {
[
https://issues.apache.org/jira/browse/LOG4J2-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-316:
Attachment: tmp_140123_0205221834269922.png
8 feathers
> Logo Contest Submissions
> --
Hi,
I am using log4j 1.2.17 version and have log4j.properties.
This has properties defined for Console appender and RollingFileAppender.
Our application is working good since last 3 and half years.
Now, I am trying to introduce a new property as below:
log4j.appender.A1 = org.apache.log4j.rewri
I'm fine with Nick's proposal to have two separate votes.
Remko
On Friday, January 24, 2014, Nick Williams
wrote:
> By a generic definition, this new Level is certainly an enum. And it's
> written in Java. No, it's not a Java-language official enum. But, as far as
> byte code goes, it's nearly i
I'm fine with Nick's proposal to have two separate votes.
Remko
On Friday, January 24, 2014, Nick Williams
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
I don't think we need a vote on the new level code..there's no good
technical reason to ask it to be removed, and it is likely to be
useful to some group of folks.
I think we're doing a good job on the other thread bouncing ideas of
how to handle extensible levels, and that conversation should con
See item 34 in Effective Java. You can totally extend interfaces for enums.
Although this wasn't really used properly in that bit. How about an
interface for the important methods, than an enum that implements the
interface. Then you only have to use the ugly generic notation like:
static & Level
Scott, with all respect, I disagree.
True, WRT extensible enum (this thread) I haven't seen anyone opposing this
idea. We're still fine-tuning the implementation but I haven't seen anyone
arguing against this. I don't mind making sure of that with a vote though.
However, WRT the new levels (the o
I understand folks may not 'prefer' to have the additional levels, but
if it won't cause us a maintenance burden (it won't), and it it's
already in place (it is) and it provides a simple mechanism for a
majority of the 'custom level' needs (very likely), there really isn't
much of a disagreement is
Scott, the disagreement is in purpose. There are those who believe the new
logging levels are finely-tuned additions that have their proper place in
the level hierarchy; others do not. The debate would be no different if the
levels truly were CATASTROPHE and APOCALYPSE. I am making a silly analogy,
I am discussing custom levels here with the understanding that this is a
separate topic from what the built-in levels are. Here is how I convinced
myself that custom levels are a “good thing”.
No matter which built-in levels exits, I may want custom levels. For
example, I want my app to use the fo
I am discussing custom levels here with the understanding that this is a
separate topic from what the built-in levels are. Here is how I convinced
myself that custom levels are a “good thing”.
No matter which built-in levels exits, I may want custom levels. For
example, I want my app to use the fo
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.) They are sufficient for the vast majority of
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.
Ralph
[
https://issues.apache.org/jira/browse/LOG4J2-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Brouwer updated LOG4J2-439:
-
Attachment: EncodingPatternConverter.patch
I've attached a patch for EncodingPatternConverter and
Gary,
I think that's a very cool idea!
Much more flexible, powerful and elegant than pre-defined levels could ever
be.
It definitely makes sense to design the extensible enum with this potential
usage in mind.
Remko
On Friday, January 24, 2014, Gary Gregory wrote:
> I am discussing custom leve
Yes, sorry for the extra work, but please revert the commit.
On Friday, January 24, 2014, Ralph Goers 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 rever
[
https://issues.apache.org/jira/browse/LOG4J2-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric closed LOG4J2-458.
---
Resolution: Fixed
Hi Remko,
This issue is resolved
Thanks
Eric
> Filters configuration
> -
>
>
[
https://issues.apache.org/jira/browse/LOG4J2-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13880790#comment-13880790
]
Eric commented on LOG4J2-458:
-
Hi Remko,
This issue is resolved
Thanks
Eric
> Filters configu
42 matches
Mail list logo
