I would also strongly recommend that you read through
http://www.apache.org/foundation/how-it-works.html. Rest assured that
contributions you make here will not go unnoticed.
Ralph
On Sep 6, 2013, at 2:00 PM, Paul Benedict wrote:
> Abhinav,
>
> Apache works on a "meritocracy" basis, which me
Odd, I could have sworn I fixed this. One more thing that has to work before
the release can be cut.
Ralph
On Sep 6, 2013, at 1:55 PM, Gary Gregory wrote:
> FYI:
>
> [INFO] --- maven-pdf-plugin:1.2:pdf (pdf) @ log4j ---
> [INFO] Ignoring api call removed in maven 3, no reports are generated!
Identify any Jira issues you think need to be addressed and fix them if you
can. I know of a couple I want to deal with.
Sent from my iPad
On Sep 8, 2013, at 3:29 PM, Remko Popma wrote:
> What is still outstanding before we can release beta-9? Anything I can do to
> help?
>
> Remko
That is one way to do it. I wouldn't mind adding logic into the configuration
but I'd hate to do that in XML - then it will look like Maven 1 with Jelly.
Ralph
On Sep 11, 2013, at 9:26 PM, Gary Gregory wrote:
> Hi All,
>
> I have a solution implemented locally that does not output ANSI esc
I prefer holding the discussions on the private list but voting on the public
list. Just my preference though.
Ralph
On Sep 11, 2013, at 9:35 PM, Gary Gregory wrote:
> Which ML should we discuss possible committer candidates?
>
> G
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.o
private@logging. I can't imagine holding committer discussions on members@
Ralph
On Sep 11, 2013, at 10:05 PM, Gary Gregory wrote:
> Do you mean members@ or a log4j private list?
>
> G
>
>
> On Thu, Sep 12, 2013 at 12:50 AM, Ralph Goers
> wrote:
> I prefer h
t; N
>
> On Sep 11, 2013, at 11:50 PM, Ralph Goers wrote:
>
>> I prefer holding the discussions on the private list but voting on the
>> public list. Just my preference though.
>>
>> Ralph
>>
>> On Sep 11, 2013, at 9:35 PM, Gary Gregory wro
I think I have fixed everything I wanted to and am planning on doing the
release tonight or tomorrow. If you have anything else you want to do I suggest
you do it now. I will send an email when I start the release process.
Ralph
---
This is a vote to release Log4j 2.0-beta9, the eleventh release of Log4j 2.0.
New features:
o LOG4J2-399: Allow the default file rollover strategy to define the
compression level.
o LOG4J2-338: Add TLSAppender. Also added missing license headers to several
files. Thanks to Tibor Benke.
o LOG
Well, we will need 1 more PMC +1 for the release to pass since Gary has a
different opinion.
Ralph
On Sep 16, 2013, at 3:09 AM, Christian Grobmeier wrote:
> Am 16.09.13 07:49, schrieb Ralph Goers:
>> Based on this I would also vote +1 since artifacts under the MIT license
>> ar
The vote passes with +1s from
Ralph Goers (binding)
Gary Gregory (binding)
Remko Popma
Christian Grobmeier (binding)
I will continue with the release process.
Thank you for taking the time to review the release.
Ralph
-
To
I need a chance to review this. I am uncomfortable with hardwiring this.
Sent from my iPad
On Sep 19, 2013, at 5:02 PM, Nick Williams
wrote:
> Thanks, Remko.
>
> Team: should this method Remko added be called automatically from
> LoggerContext#stop()?
>
> N
>
> On Sep 19, 2013, at 6:51 PM,
The Apache Log4j 2 team is pleased to announce the Log4j 2.0-beta9 release!
Apache log4j is a well known framework for logging application behavior. Log4j
2 is an upgrade to
Log4j that provides significant improvements over its predecessor, Log4j 1.x,
and provides
many of the improvements availa
I don't really like "Log4jException". Log4j is a noun while Logging is a verb -
it is not meant to imply an exception that applies to all of org.apache.logging
but an exception performing logging within Log4j. As such, its current name and
package seem quite appropriate to me.
Ralph
On Sep 23,
I don't really like "Log4jException". Log4j is a noun while Logging is a verb -
it is not meant to imply an exception that applies to all of org.apache.logging
but an exception performing logging within Log4j. As such, its current name and
package seem quite appropriate to me.
Ralph
On Sep 23,
verb and noun patterns are valid IMO.
>
> G
>
>
> On Mon, Sep 23, 2013 at 7:17 PM, Ralph Goers
> wrote:
> I don't really like "Log4jException". Log4j is a noun while Logging is a verb
> - it is not meant to imply an exception that applies to all of
>
Yeah, but It doesn't really much matter if it is fixed now or not. I can
change the release number when the release is performed fairly easily.
Ralph
On Sep 23, 2013, at 4:34 PM, Gary Gregory wrote:
> ...is currently 2.0RC1, should it not be 2.0-RC1, with a dash, like all of
> our other previ
Making the SLF4J Logger serializable doesn't imply that the Log4j Logger needs
to be Serializable. Since the Loggers in both Logback and the SLF4J wrapper to
Log4j 1.x are Serializable it seems obvious to me that the SLF4J to Log4j 2
Logger should also be.
As for the Log4j 2 Logger it might ma
Remko, thanks for the contributions you have made so far. Congratulations on
this new role!
Sent from my iPad
> On Sep 28, 2013, at 11:08 AM, "Christian Grobmeier"
> wrote:
>
> Dear all,
>
> I am very happy that Remko Popma accepted our invitation to join the Apache
> Logging PMC.
>
> Best
I installed a Jira app on my iPad that seems to work OK.
Ralph
On Sep 29, 2013, at 1:56 PM, Remko Popma wrote:
> I have the same problem on my iPhone.
> Mobile Safari and Chrome both have this issue. Mobile Opera doesn't.
> (Scrolling works with desktop version.)
>
> On Monday, September 30,
Jira Issue Tracker version 4.3. The Seller is listed as Rahim Kanjiyani.
Ralph
On Sep 29, 2013, at 6:23 PM, Gary Gregory wrote:
> On Sun, Sep 29, 2013 at 7:45 PM, Ralph Goers
> wrote:
> I installed a Jira app on my iPad that seems to work OK.
>
> Which app is that?
>
>
Is there some reason you can't do:
public static final Marker VERBOSE_MARKER = MarkerManager.getMarker("VERBOSE");
and then logger.info(VERBOSE_MARKER, "Reading Accounts");
then in your configuration you would do
and finally, in your Appender you could use a PatternLayout that includes
pat
Try the FailoverAppender. See
http://logging.apache.org/log4j/2.x/manual/appenders.html#FailoverAppender.
Ralph
On Oct 9, 2013, at 10:25 AM, Sudharma Puranik
wrote:
> Hello,
>
> I have a special case of logging, that is , whenever I get an Error I would
> want to log to disk. Kind of a Dum
the log4j2 provide any
> dropin solution for plugins? Or is it that , do you have any other way of
> doing it?
>
> kindly help
>
> -Sudharma
>
>
>> On Thu, Oct 10, 2013 at 12:13 AM, Ralph Goers
>> wrote:
>> Try the FailoverAppender. See
>> http://
> -Sudharma
>
>
>> On Thu, Oct 10, 2013 at 3:48 PM, Ralph Goers wrote:
>> The FailoverAppender didn't work for you? If not, why?
>>
>> To get your plugin to be found you either need to add its package to the
>> packages attribute of the configuration el
first fails,
> but failure for me is in application not appender.
>
> Is my thinking wrong anywhere?
>
> -Sudharma
>
>
> On Fri, Oct 11, 2013 at 10:55 AM, Ralph Goers wrote:
> Did you make sure to specify ignoreExceptions="false" on the appender to be
>
I won't have a chance to review this until this evening if you need my vote...
Ralph
> On Oct 17, 2013, at 2:12 AM, "Christian Grobmeier"
> wrote:
>
> Gary do you have any serious concerns with this release?
> The vote closes later today - last chance to object :-)
>
>> On 16 Oct 2013, at 17:
If you have the 3 +1 votes go ahead and call it. I have been very busy at my
new job and haven't had much time.
Ralph
On Oct 18, 2013, at 11:18 AM, Christian Grobmeier wrote:
> my own +1
>
> On 14 Oct 2013, at 14:00, Christian Grobmeier wrote:
>
> Dear all,
>
> this is a vote for a new Apa
I am trying to find a bit more time to work on Log4j again. I see quite a few
issues that I would like to address and think I will need about 2 weeks to
complete them so I am tentatively targeting the middle of the month for the
next release. The question in my mind is whether the next releas
There have been many candidates submitted in the Logo contest [1] which can be
viewed at http://www.fdmhosting.com/log4j2/. I am going to be honest and say
that none of them grabs me and says “that’s the one”, although I like the ideas
expressed in quite a few of them. I definitely like the pl
-- Original message
>> From: Paul Benedict
>> Date:01/02/2014 11:49 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: Re: Logo Contest
>>
>> I think holding up the final release for the logo shouldn't be too desired.
>> I am patien
to do. People are using log4j now
> in beta form. Another beta/rc will not hurt. But once 2.0 is out, we are set.
>
> Gary
>
>
>
> On 2 Jan 2014, at 14:04, Gary Gregory wrote:
>
> Make it RC or another beta IMO. Once 2.0 is out you cannot unhinged that
> bell.
>
tially stop
> (other than the occasional bug fix commit).
>
> I'd hate for us to end up in the same place with log4j2.
>
> Scott
>
> On 1/3/14, Ralph Goers wrote:
>> What are contemplating changing in log4j-api?
>>
>> Ralph
>>
>>
>>
The tests weren't migrated from junit 3, although I spent many years working
with it. Frankly, until I saw your patch today I was unaware of directly using
Hamcrest. Since junit uses it I really have no problem if we do if it makes the
tests more readable.
Ralph
> On Jan 5, 2014, at 12:38 AM,
Actually, there is a decent chance it will be the GA release. We are waiting
for feedback from Gary on what he thinks.
FWIW, there is no “Project Manager” here. We make decisions based on consensus.
However, the release manager does get some latitude.
Ralph
On Jan 11, 2014, at 10:52 AM, Matt
I have frequently been seeing a unit test fail on my Mac and it just failed
again in my Windows VM. Can someone more familiar with this take a look to
determine why it frequently fails?
Thanks,
Ralph
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.432 sec <<<
FAILURE! - in
I’ve always had reservations about the servlet 3.0 automatic configuration
because if the log4j jar is present it can’t be disabled or be modified by the
end user. We’ve had some issues with Spring initialization and now LOG4J2-452
reinforces that. I would propose that if we want to keep it tha
I understand the need for CONFIG. However it isn’t clear to me whether it
belongs between INFO and WARN or DEBUG and INFO. That is because it typically
would be used to log configuration during startup. That doesn’t necessarily
imply that you would then want to see all INFO messages as well.
Oops. I just noticed you proposed that VERBOSE be between INFO and DEBUG. Now
that I don’t understand. My experience is that VERBOSE is usually more detailed
than debug messages, not less.
Ralph
On Jan 18, 2014, at 9:44 AM, Ralph Goers wrote:
> I understand the need for CONFIG. However
:35 PM, Ralph Goers
> wrote:
> I’ve always had reservations about the servlet 3.0 automatic configuration
> because if the log4j jar is present it can’t be disabled or be modified by
> the end user. We’ve had some issues with Spring initialization and now
> LOG4J2-452 reinfor
ntion of course, but it would be nice to have the
> distinction available through levels for developers to use.
>
> I see TRACE as method entry and exit type of logging, *very* *low* level
> stuff.
>
> We could also have both (ducking for projectiles):
>
> INFO
> VER
If you want a level between DEBUG and TRACE I guess I’m OK with that too. Using
FINER makes more sense than STEP to me since the levels in JUL are:
FINE = DEBUG
FINER = ?
FINEST = TRACE
However, I really don’t like that name either.
Ralph
On Jan 18, 2014, at 11:21 AM, Ralph Goers wrote
The problem I have with CONFIG is that the applications I deployed usually set
their default log level to ERROR, so enabling CONFIG would also enable WARN,
which isn’t what was desired. Using a CONFIG marker eliminates this problem.
Ralph
On Jan 18, 2014, at 12:30 PM, Nicholas Williams
wrote
be enabled
regardless of its level and enabling it doesn’t imply enabling other levels.
Ralph
On Jan 18, 2014, at 1:03 PM, Gary Gregory wrote:
> On Sat, Jan 18, 2014 at 2:21 PM, Ralph Goers
> wrote:
> STEP? No clue what that means.
>
> Gary, if you want to implement VERBO
regory wrote:
>
>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers
>> wrote:
>> I’ve always had reservations about the servlet 3.0 automatic configuration
>> because if the log4j jar is present it can’t be disabled or be modified by
>> the end user. We’ve had s
gt; to go for servlet 3.0.
>
>
> On 18 January 2014 15:19, Ralph Goers wrote:
> I was hoping to start the GA release sooner than that.
>
> If the servlet context initializer is disabled then the listener should still
> be allowed.
>
> Ralph
>
> On Jan 18
orgive brief replies
> and frequent typos
>
> On Jan 18, 2014, at 14:01, Matt Sicker wrote:
>
>> Markers all around! No logging levels, just allow markers to have ordinals
>> or bit-flags to allow more flexible filtering.
>>
>> Sorry, nothing useful to add be
8, 2014, at 14:01, Matt Sicker wrote:
>
>> Markers all around! No logging levels, just allow markers to have ordinals
>> or bit-flags to allow more flexible filtering.
>>
>> Sorry, nothing useful to add beyond wild speculations.
>>
>>
>> On 18 Januar
Doesn't logger.quiet(“Error doing something, exception) just seem really
strange? I’m guessing for QUIET we wouldn’t need to implement all of the
individual APIs . That probably isn’t true of LIFECYCLE.
Ralph
On Jan 18, 2014, at 2:29 PM, Ralph Goers wrote:
> Hmm. I actually like L
---
Test set:
org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManagerTest
---
Tests run: 5, Failures: 1, Errors: 0, Skipped:
---
Test set: org.apache.logging.log4j.core.pattern.PatternParserTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.368 sec
OK. The problem with this one seems pretty obvious. The test will only pass one
day a month as it is including the day of the month in the expected pattern.
Ralph
On Jan 19, 2014, at 8:05 PM, Ralph Goers wrote
Fixed in revision 1559625.
Ralph
On Jan 19, 2014, at 8:26 PM, Ralph Goers wrote:
> OK. The problem with this one seems pretty obvious. The test will only pass
> one day a month as it is including the day of the month in the expected
> pattern.
>
> Ralph
>
> On Jan
I ran the test by itself and then ran the full build a couple of times and it
passed. There must be a timing problem in the test.
Ralph
On Jan 19, 2014, at 8:03 PM, Ralph Goers wrote:
> ---
> Te
t;>>>>> Can you talk a little more why CONFIG > INFO (and not INFO > CONFIG)?
>>>>>>> For me, I would use VERBOSE for configuration logging.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>&
you that something is
> needed more on the INFO side of DEBUG rather than the TRACE side. That would
> allow DEBUG to be used for what it's really meant for. So I'm fine with
> VERBOSE instead.
>
> My reason for putting CONFIG between INFO and WARN is simple: I ALWAYS want
Yes.
https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/java/org/apache/logging/log4j/core/appender/rewrite/RewriteAppenderTest.java
uses
https://svn.apache.org/repos/asf/logging/log4j/log4j2/trunk/log4j-core/src/test/resources/log4j-rewrite.xml
which uses a MapRew
eople 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 wrote:
> On Tue, Jan 21, 2014 at 11:33 AM, Paul Benedict wrote:
> On Tue, Jan 21, 2014 at 10:25 AM, Ral
Gary - since this will break binary compatibility it definitely needs a comment
in changes.xml. I will also want to call it out in the release notes.
Ralph
On Jan 21, 2014, at 7:10 PM, ggreg...@apache.org wrote:
> Author: ggregory
> Date: Wed Jan 22 03:10:53 2014
> New Revision: 1560242
>
> U
I am fine with DIAG. I had always thought INFO was the abbreviation for
INFORMATIONAL, which is way too long.
Ralph
> On Jan 22, 2014, at 6:21 AM, Gary Gregory wrote:
>
>> On Wed, Jan 22, 2014 at 1:33 AM, Ralph Goers
>> wrote:
>> First, I assume you m
gt; definitely custom things people should implement themselves.
>
> Paul
>
>
> On Wed, Jan 22, 2014 at 12:33 AM, Ralph Goers
> wrote:
> First, I assume you meant to code “implements LogLevelStrength” instead of
> “extends LogLevelStrength” since an enum already im
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
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
Actually, Log4j 1.x issues belong on bugzilla. But for this case I guess it
doesn’t matter.
Ralph
On Jan 24, 2014, at 7:56 AM, Remko Popma wrote:
> Sai,
>
> Sorry for the slow response.
> First, please be aware that the team is fully focussed on log4j-2.0 and not
> spending effort on log4j
mers on this list. So I think we can reasonable
> assume that a large fraction of users would also not like this change.
>
> On top of that, we have a more powerful and elegant alternative solution
> that makes adding pre-defined levels unnecessary.
> Sorry, but I veto the commit.
>
I would not be in favor of removing FATAL for no other reason than it makes
mapping levels from SLF4J and Commons Logging easy.
Ralph
On Jan 24, 2014, at 12:20 PM, Scott Deboy wrote:
> I think the 'levels=severity' model broke down a bit when we added
> TRACE, and FATAL is never used, so I thi
#x27;s remove fatal.
>
> Scott
>
>
> On 1/24/14, Remko Popma wrote:
> I'm not questioning your experience, and I believe you when you say
> that
> the proposed levels would be a perfect match for your current work
> environment.
>
> However, out of the eight pe
I am working on the implementation of custom levels now. I should have it done
today.
Ralph
On Jan 24, 2014, at 7:07 PM, Remko Popma wrote:
> What is the best way to make progress on the custom levels implementation?
>
> Do we re-open LOG4J-41 or start a fresh Jira ticket? For implementation
split: Some wanted to go with my extensible enum, others
> wanted to change Level to an interface and make a Levels enum.
>
> So I'm a bit confused. Which implementation are you working on?
>
> Nick
>
> On Jan 25, 2014, at 7:08 AM, Ralph Goers wrote:
>
>> I a
gree on that.
>
> Nick
>
> Sent from my iPhone, so please forgive brief replies and frequent typos
>
> On Jan 25, 2014, at 11:20, Ralph Goers wrote:
>
>> I have not heard anyone disagree with allowing custom Levels. The
>> disagreement I am hearing is over adding new p
e
> Level.toLevel(String, Level) method would find the custom instance in a
> static HashMap in the Level superclass.)
>
> On Sunday, January 26, 2014, Ralph Goers wrote:
> Here is what I am implementing:
>
> 1. Level is now an Interface. This allows the vast amount of code to
Hmm. It seems I am going to have to do something to force the registration as
the custom level class hasn’t been constructed before the levels are referenced
in the configuration.
Ralph
On Jan 25, 2014, at 3:43 PM, Ralph Goers wrote:
> In the constructor each of them calls Levels.addLe
>
> On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers
> wrote:
> Hmm. It seems I am going to have to do something to force the registration as
> the custom level class hasn’t been constructed before the levels are
> referenced in the configuration.
>
> Ralph
>
> O
iscovered, serialization works automatically, and extenders
> don't have to do any extra work in the constructor. Why are we making this so
> difficult?
>
> Nick
>
> Sent from my iPhone, so please forgive brief replies and frequent typos
>
> On Jan 25, 2014, at 15:18, Ralph
Rats. StdLevel isn’t a Level because it can’t extend it if it is an enum, so I
can’t initialize the levels using that. So no switch statements if we go this
way. I’ll keep looking at it but that makes this solution less appealing to me.
Ralph
On Jan 25, 2014, at 6:05 PM, Ralph Goers wrote
e a class at all? What about
> just having it defined in the configuration.
>
> On Jan 25, 2014 4:37 PM, "Ralph Goers" wrote:
> Because we don’t know the class name that the Level belongs to. It is
> referenced in the configuration just as “DIAG”, not
> “org.apache.
#x27;re dealing with an
> unknown quantity of levels. You'll have to look them up in a registry/map.
> That's the trade off of an extensible system.
>
> On Jan 25, 2014 8:13 PM, "Ralph Goers" wrote:
> Rats. StdLevel isn’t a Level because it can’t extend it i
y to add support for users to define level entries (name and
> value pairs as a new element in the config) and have us do the work to make
> those valid? That would get get rid of my request for additional levels,
> right?
>
> On Jan 25, 2014 6:15 PM, "Ralph Goers" wrote:
s just return "level " + level.toString(); ?
> * log4j-to-slf4j: org.apache.logging.slf4j.SLF4JLogger
>
>
>
> On Sun, Jan 26, 2014 at 11:41 AM, Ralph Goers
> wrote:
> I am not sure what you mean by this. I have already succeeded in adding
> custom level names
an get to what we have now, but yes, that was what
> I had in mind...
>
>
> On Sun, Jan 26, 2014 at 12:00 PM, Ralph Goers
> wrote:
> Wow - I had never thought about using a Java Proxy to implement all those
> methods before. That would be a piece of cake.
>
> Ralph
As I am working on this I just want to point out a number of issues with the
code below:
1. The class is abstract. The static block is doing a bunch of new Level()
invocations which obviously generate compile errors on an abstract class. I
had to make it be a non-abstract class.
2. As I pointe
StatusLogger
> * log4j-core: org.apache.logging.log4j.core.net.Severity
> * log4j-core: org.apache.logging.log4j.core.pattern.LevelPatternConverter -
> perhaps just return "level " + level.toString(); ?
> * log4j-to-slf4j: org.apache.logging.slf4j.SLF4JLogger
>
>
>
> On Sun, Jan 26, 2014 at 11:41 AM, Ralph
oLevel() and values()
> levels are called.
> It turns out they are only called during reconfiguration, so no real need to
> optimize these methods.
> I would argue that simple synchronization may be best in this case.
>
> Remko
>
>
>
> On Sun, Jan 26, 2014 at
vel() and Level.values() methods may be simplest.
>
> Which of the last two is best depends on how often the toLevel() and values()
> levels are called.
> It turns out they are only called during reconfiguration, so no real need to
> optimize these methods.
> I would argue that si
al" java enums may be
> easier to deal with than the extensible enum approach.
>
>
> On Sun, Jan 26, 2014 at 2:30 PM, Ralph Goers
> wrote:
> Out of curiosity, what exactly is the benefit of declaring the class abstract
> when it has a protected constructor? It seems
ay be simplest.
>>
>> Which of the last two is best depends on how often the toLevel() and
>> values() levels are called.
>> It turns out they are only called during reconfiguration, so no real need to
>> optimize these methods.
>> I would argue that simple
t; moment we make it extensible?
>
>> On Sunday, January 26, 2014, Ralph Goers wrote:
>> A malicious app could do
>>
>> for (int i=0; i < 10; ++i) {
>> new Level(“Level” + i, 1000 + i){};
>> }
>>
>> Sure idiots can do lots of bad thing
.
Are their any objections to me checking this in? I’ll be doing the commit at
around noon Pacific Daylight Time if I don’t hear any.
Ralph
On Jan 25, 2014, at 7:08 AM, Ralph Goers wrote:
> I am working on the implementation of custom levels now. I should have it
> done today.
>
gt;
> On Sunday, January 26, 2014, Ralph Goers wrote:
> I have completed the work on custom levels. It uses a variation of Nick’s
> “extensible enum” class. The major difference with what he proposed is that
> the custom enums must be declared in a class annotated with
> @Plu
and to a lesser extent
> logfilepatternreceiver.
>
> Scott
> On Jan 26, 2014 7:28 AM, "Scott Deboy" wrote:
> So I assume we could build on this by adding the ability to generate these
> custom levels from the config, with no user provided class required?
>
>
>
>
t;protected Level(String name, int level, StandardLevel
> mapToOtherFrameworksAs) {
>this(name, level);
>this.standardLevel = mapToOtherFrameworksAs;
>}
>
>private Level(String name, int level) {
>// same as now
>this.standardLevel = t
upporting both sides of the argument.
>
> Nick
>
> Sent from my iPhone, so please forgive brief replies and frequent typos
>
> On Jan 18, 2014, at 10:54, Gary Gregory wrote:
>
>> On Sat, Jan 18, 2014 at 12:35 PM, Ralph Goers
>> wrote:
>> I’ve always
ardLevel;
>
>protected Level(String name, int level, StandardLevel
> mapToOtherFrameworksAs) {
>this(name, level);
>this.standardLevel = mapToOtherFrameworksAs;
>}
>
>private Level(String name, int level) {
>// same as now
>this.stan
I made most of the changes.
I moved StandardLevel to a separate file in the spi sub-package. The actual
level values are defined there and then referenced in Level. This way each
Level can be associated with a StandardLevel in its constructor.
Ralph
On Jan 26, 2014, at 1:40 PM, Ralph Goers
>}
>
>public enum StandardLevel {
>OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL
>}
>
> Thoughts?
>
> N
>
> On Jan 26, 2014, at 4:02 PM, Ralph Goers wrote:
>
>> I do have one other comment. You mention that the ordinal value isn’t
&g
what you are thinking of?
>>
>> I would be fine with that too, but would like to first focus on generating
>> the extended Logger interface.
>>
>>
>>
>> On Mon, Jan 27, 2014 at 5:29 AM, Scott Deboy wrote:
>> Is there a way to generate code/update
of whatever
interface it might implement.
Ralph
On Jan 26, 2014, at 4:10 PM, Ralph Goers wrote:
> My first implementation used a real enum that implemented a Level interface.
> I have to agree with Nick that what is currently committed is simpler.
>
> Ralph
>
> On Jan 26
e Level subclass from
>> configuration as well. I suppose that would entail adding a new
>> element, with sub-elements like ... Is
>> that what you are thinking of?
>>
>> I would be fine with that too, but would like to first focus on generating
>> the extend
from
>> configuration as well. I suppose that would entail adding a new
>> element, with sub-elements like ... Is
>> that what you are thinking of?
>>
>> I would be fine with that too, but would like to first focus on generating
>> the extended Logger int
1 - 100 of 4790 matches
Mail list logo
