I was going to make the change but ran out of time...
No rush though, I just didn't want to forget about it and have it cause
issues later in the generated code. (I'll bring this - maintenance - up in
the other thread. )
On Wednesday, January 29, 2014, Ralph Goers
>
wrote:
> I can do it but it wo
I can do it but it won't be for another 8 hrs or so. If you need it sooner go
ahead.
Sent from my iPad
> On Jan 28, 2014, at 9:00 AM, Remko Popma wrote:
>
> Who will make this change (getOrCreateLevel -> forName) ?
> I'm asking because I'm calling this method in the generated wrapper source
>
Who will make this change (getOrCreateLevel -> forName) ?
I'm asking because I'm calling this method in the generated wrapper source
code...
On Mon, Jan 27, 2014 at 12:55 PM, Nick Williams <
nicho...@nicholaswilliams.net> wrote:
> Okay. I'm good with "forName," then.
>
> N
>
> On Jan 26, 2014, a
> From: Ralph Goers
> Date:01/27/2014 11:19 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Enums and Custom Levels - completed.
>
> If the user creates a custom Logger Wrapper then they can just code against
> that and not use an interface, correct?
>
> Ral
Yes that's the idea.
Gary
Original message
From: Ralph Goers
Date:01/27/2014 11:19 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Enums and Custom Levels - completed.
If the user creates a custom Logger Wrapper then they can just code against
that and not u
If the user creates a custom Logger Wrapper then they can just code against
that and not use an interface, correct?
Ralph
On Jan 27, 2014, at 6:40 AM, Nick Williams
wrote:
> Wrapping a logger /implementation/ is fine. But the user needs an /interface/
> to program against. That interface sho
Wrapping a logger /implementation/ is fine. But the user needs an /interface/
to program against. That interface should extend Logger rather than re-define
all of Logger's methods.
Nick
On Jan 27, 2014, at 8:24 AM, Gary Gregory wrote:
> Please note that in the case of domain specific logging (
Please note that in the case of domain specific logging (DSL!), I do not
want to extend, I want to wrap a logger. See my DEFCON example.
Gary
On Sun, Jan 26, 2014 at 6:51 PM, Nick Williams <
nicho...@nicholaswilliams.net> wrote:
> Generating a logger /interface/ is going to be hard. Sure, writi
Okay. I'm good with "forName," then.
N
On Jan 26, 2014, at 9:51 PM, Ralph Goers wrote:
> I disagree - you are getting the Level that matches the name, so forName does
> describe what is happening.
>
> See the Javadoc on the second question. The intValue is ignored unless the
> Level is creat
I disagree - you are getting the Level that matches the name, so forName does
describe what is happening.
See the Javadoc on the second question. The intValue is ignored unless the
Level is created. Yes, that could lead to some problems if there are
conflicts, but I think returning the regist
Perhaps if we called the priority or ordinal "power", then we'd have a
great time with the naming scheme?
On 26 January 2014 21:46, Nick Williams wrote:
> Level.forName wouldn't work--it's not just "for name," it's for the name
> /and/ the level. But it must be unique by the name.
>
> For that m
I second my suggestion!
On 26 January 2014 21:44, Ralph Goers wrote:
> My first gut reaction was confusion over Class.forName(). But then in
> thinking about it that name does behave a lot like what Class.forName()
> does, except with a Level. So I think I do like it better than the current
>
Level.forName wouldn't work--it's not just "for name," it's for the name /and/
the level. But it must be unique by the name.
For that matter, what are we to do in the following situation?
Level.getOrCreate("DIAG", 150);
...
Level.getOrCreate("DIAG", 250);
They're not going to get wh
My first gut reaction was confusion over Class.forName(). But then in thinking
about it that name does behave a lot like what Class.forName() does, except
with a Level. So I think I do like it better than the current name.
Any other thoughts or opinions?
Ralph
On Jan 26, 2014, at 7:28 PM,
How about Level.forName()?
On 26 January 2014 21:06, Ralph Goers wrote:
> No objections on spawning a separate thread for discussion 2.
>
> I also am not in love with the method name but it does describe what it
> does. If anyone has any ideas on a better name please suggest it (we are
> talki
Understood. I can't commit from work but I can fix this when I get home
tonight.
On Monday, January 27, 2014, Ralph Goers wrote:
> You mentioned that before and I didn’t check since it has been that way
> from the beginning. Yes it looks like a bug to me.
>
> Ralph
>
> On Jan 26, 2014, at 7:06
You mentioned that before and I didn’t check since it has been that way from
the beginning. Yes it looks like a bug to me.
Ralph
On Jan 26, 2014, at 7:06 PM, Remko Popma wrote:
> The switch in o.a.l.Category.getEffectiveLevel() in log4j-1.2-api is missing
> the FATAL level (and perhaps OFF
No objections on spawning a separate thread for discussion 2.
I also am not in love with the method name but it does describe what it does.
If anyone has any ideas on a better name please suggest it (we are talking
about the getOrCreateLevel method name).
Ralph
On Jan 26, 2014, at 6:59 PM, N
The switch in o.a.l.Category.getEffectiveLevel() in log4j-1.2-api is
missing the FATAL level (and perhaps OFF also).
Is this intentional?
On Monday, January 27, 2014, Ralph Goers wrote:
> I modified Level to be final and have a private constructor. I added a
> static method named getOrCreateLev
If you break off into another thread, I'll be watching; I'll throw in my 2
cents on how to make a custom Logger interface once that occurs.
On Sun, Jan 26, 2014 at 9:01 PM, Ralph Goers wrote:
> Yes, logger.log(MyCustomLEvels.LEVEL1, “message”); works right now. See
> the ExtendedLevels class in
Yes, logger.log(MyCustomLEvels.LEVEL1, “message”); works right now. See the
ExtendedLevels class in log4j-core test as an example on how to declare the
level.
I think several of us think that finding a way to make it easy to create
extended logger methods would be very nice, but I don’t believ
There are two separate discussions going on here, so it's easy to get lost. We
should probably split discussions again.
Discussion 1: The finer details of custom levels. I'm fine with using a static
factory method and making the constructor private, but I'm not a big fan of the
name. Just sound
I got lost in the discussion. Can someone please clarify... Is the custom
logging interface a nice-to-have or a requirement of the system?
I was hoping simply someone could write this (pseudocode below):
logger.log(MyCustomLevels.LEVEL1, "message");
...so no different interface should be required
Now Level can't be used in an annotation. Since it supports string names
for levels, should I just use Level.toLevel?
On 26 January 2014 19:55, Ralph Goers wrote:
> I think I must be misunderstanding the part about “If those levels were
> added…”. I don’t understand how a level can be added to
I modified Level to be final and have a private constructor. I added a static
method named getOrCreateLevel. Custom extensions should use that method to
create the static reference. This allows the new Level to be declared in
multiple places without a problem as they will all get the same Lev
I think I must be misunderstanding the part about “If those levels were
added…”. I don’t understand how a level can be added to a class from the
config such that it is usable by a programmer at compile time.
Ralph
On Jan 26, 2014, at 5:24 PM, Scott Deboy wrote:
> Couldn't we no-op instead of
Why would we want that? It is inconsistent with how we currently use Levels and
I think it could lead to confusion.
What I think should happen is that this Logger wrapper is also where the custom
level should be declared.
Ralph
On Jan 26, 2014, at 5:32 PM, Nick Williams
wrote:
> Sorry, I wa
Sorry, I was leaving the method names off because the user can name the methods
whatever they want to. They aren't important to the signature as far as Log4j
is concerned.
You /could/ get the level name from the method name, yes. Using an annotation
would allow the user to have a constant, perh
We can’t no-op because the user is doing
public static Level NOTE = new Level(“NOTE”, 123){};
Of course, this will generate a new object, not return a preexisting one. The
only way around this would be to use a Level factory pattern such as
public static Level NOTE = Level.getOrCreateLevel(“NO
I think I am missing something.
First, void(Marker, Message) isn’t a valid method signature so I am not sure
what you are really intending. It looks like you specifically did not add the
level to the method name and are planning on getting it from the annotation?
If so, I don’t see how that w
Couldn't we no-op instead of throw if the same identical level were
registered?
If those levels were then added to the same custom level class from the
config, could we use that single class in the logger calls?
On Jan 26, 2014 5:15 PM, "Ralph Goers" wrote:
> I am certain I could create a Level
I am certain I could create a LevelPlugin that would allow you to define one or
more Levels in the configuration, but to use that Level the user would have to
code:
logger.log(Level.toLevel(“DIAG”), “hello world”);
In order to directly reference the level it has to be declared as a static from
> Gary
>
>
> Original message
> From: Remko Popma
> Date:01/26/2014 18:17 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Enums and Custom Levels - completed.
>
> Scott,
> The way I interpreted Gary's idea was that based on user-specified custom
Please read my message again. I talk about wrapping not extending.
Gary
Original message
From: Remko Popma
Date:01/26/2014 18:17 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Enums and Custom Levels - completed.
Scott,
The way I interpreted Gary's idea was
If the explicit values of the enum aren't used, then the logger methods
that take a level would still work just fine. That's with the funky & Level> generic, too, right?
On 26 January 2014 18:14, Ralph Goers wrote:
> Oh, actually I used an Interface for Level and an enum for the standard
> lev
Oh, actually I used an Interface for Level and an enum for the standard levels,
so I didn’t try what you are suggesting. I don’t see how what you are
proposing would work since all the Logger methods take a Level. If Level is an
enum then only the values defined in it can be used, regardless o
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, 2014, at 4:00 PM, Matt Sicker wrote:
> Don't annotation processing plugins work well in IDEs? Either way, there's a
> maven plu
I think this is very similar to my most recent commit. Since you are OK with
removing the ordinal I am going to do that along with fix the problem Remko
mentioned.
Ralph
On Jan 26, 2014, at 2:40 PM, Nick Williams
wrote:
> I would be OK with getting rid of the ordinal. It makes it less enum-
I have one goal: to remove my request for new built in levels by allowing
the levels to be defined strictly via configuration. I agree there may be
some hurdles but that's my goal.
I'd like to avoid the requirement that users provide their own level
implementation or use a different API.
Scott
O
Don't annotation processing plugins work well in IDEs? Either way, there's
a maven plugin already available for doing that, and javac has some sort of
support for it already.
Also, I'm still advocating for using a real enum for Level while providing
a Level interface for all the relevant methods.
Generating a logger /interface/ is going to be hard. Sure, writing the code
automatically will be a piece of cake. But then what do we do with that code?
The user needs to program against it. So we have to have a command-line utility
or Maven/Ant plug-in to generate the source pre-compile. Howev
Yes that's what I was thinking.
Scott
On Jan 26, 2014 3:18 PM, "Remko Popma" wrote:
> Scott,
> The way I interpreted Gary's idea was that based on user-specified custom
> levels, we would generate an extension of the Logger interface that has a
> method for each of the custom levels (well, actua
I agree. The circumstance that could cause a problem here would be rare, but
not impossible. We should use Remko's code here.
Nick
On Jan 26, 2014, at 5:20 PM, Remko Popma wrote:
> By the way, there may be a small concurrency bug in the Level.values() static
> method. This may be better:
>
>
By the way, there may be a small concurrency bug in the Level.values()
static method. This may be better:
public static Level[] values() {
Collection values = Level.levels.values();
return values.toArray(new Level[values.size()]); // use value
collection size, not map size
Scott,
The way I interpreted Gary's idea was that based on user-specified custom
levels, we would generate an extension of the Logger interface that has a
method for each of the custom levels (well, actually 14 methods for each
level :-) ).
I haven't really thought about how users would specify the
+1 to everything Nick said.
On 26 January 2014 16:40, Nick Williams wrote:
> I would be OK with getting rid of the ordinal. It makes it less enum-like,
> but I agree that the ordinal really has little purpose now. The intLevel is
> more important.
>
> Here may be the best approach I can think of
I would be OK with getting rid of the ordinal. It makes it less enum-like, but
I agree that the ordinal really has little purpose now. The intLevel is more
important.
Here may be the best approach I can think of for calculating the
StandardLevel-equivalent on instantiation:
public static L
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 w
I do have one other comment. You mention that the ordinal value isn’t
guaranteed because the levels might be instantiated in a different order each
time. An alternative wold be to just get rid of the ordinal. It isn’t used
anywhere by anything and when custom values are added they will be adde
I agree with most of this and will make the suggested changes. At least up to
the point of getting rid of the StandardLevel enum. That is used in too many
places to map to some other framework. I agree that doing the calculation every
time is not the right way to go and will see what I can do,
Some (ok, a lot of) feedback:
- `private static ConcurrentMap levels` should be final.
- `private static Object constructorLock` should be final. In fact, code
inspection flags this as a warning since code synchronizes on it.
- The standard Level constants should be instantiated in a static ini
Is there a way to generate code/update the Levels enumeration so a new
Level class isn't required?
Would be great to be able to use logger.detail("Detail message");
Is that what you're thinking of, Remko?
On 1/26/14, Ralph Goers wrote:
> I haven’t done anything to directly do that. However, cus
I haven’t done anything to directly do that. However, custom levels need to be
mapped to the standard levels in several places. It would be simple to add
support for that wherever you want it. Level.StdLevel.getStdLevel() is the
method used to do that.
Ralph
On Jan 26, 2014, at 7:45 AM, Scott
I’ve committed the changes. Take a look at ExtendedLevels.java,
ExtendedLevelTest.java and log4j-customLevel.xml in the log4j-core test
directories to see how it works.
Ralph
On Jan 26, 2014, at 1:19 AM, Remko Popma wrote:
> I'm very curious! Can't wait to see it. Go for it!
>
> On Sunday,
Never mind I see you just committed. :-)
I'll review and provide feedback if necessary.
N
On Jan 26, 2014, at 1:36 PM, Nick Williams wrote:
> Can you post a diff or the related files somewhere? Obviously it can be
> tweaked after commit if necessary, but I'd like to see if there's anything
>
Can you post a diff or the related files somewhere? Obviously it can be tweaked
after commit if necessary, but I'd like to see if there's anything major that
sticks out to me before you commit.
Thanks,
Nick
On Jan 26, 2014, at 2:57 AM, Ralph Goers wrote:
> I have completed the work on custom
Are these serialization-wise going to be the same as standard levels?
Receivers and apps like Chainsaw would benefit from not requiring the
originating level class be included in the classpath.
I'm thinking about socketreceiver and to a lesser extent
logfilepatternreceiver.
Scott
On Jan 26, 201
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?
On Jan 26, 2014 12:58 AM, "Ralph Goers" wrote:
>
> I have completed the work on custom levels. It uses a variation of
Nick’s “extensible enum” class.
> From: Remko Popma
> Date:01/26/2014 00:13 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Enums and Custom Levels
>
> Ralph,
> I copied Nick's code _as is_ and had no compile errors.
> The class is abstract, but instances are defined in the static bloc
Enums and Custom Levels
Ralph,
I copied Nick's code _as is_ and had no compile errors.
The class is abstract, but instances are defined in the static block as:
OFF = new Level("OFF", 0) {}; // note the {}: this creates an anonymous
concrete subclass
I agree that read access needs t
I'm very curious! Can't wait to see it. Go for it!
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
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 @Plugin(name=“”
category=“Level”) for them to be usable during configuration.
A
They can already do the same thing with loggers right?
Scott
On Jan 25, 2014 10:19 PM, "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 things but I don’t think Levels should be
> q
It was a lot harder when each custom extension was an enum implementing an
interface. There was no way to do a new on it.
Ralph
> On Jan 25, 2014, at 10:33 PM, Remko Popma wrote:
>
> Hm...
> Doesn't it become nearly impossible to protect against malicious intent, the
> moment we make it exten
Hm...
Doesn't it become nearly impossible to protect against malicious intent, the
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
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 things but I don’t think Levels should be quite
that flexible.
Ralph
On Jan 25, 2014, at 9:39 PM, Remko Popma wrote:
> I don't think client code can do new Level(
I wanted to have my cake and eat it too. I want the standard levels to be part
of an enumeration so I can use switch. The way the code was written I couldn’t
do that. I’ve figured out another way. I have a StdLevel enum embedded in the
Level class.
Ralph
On Jan 25, 2014, at 9:39 PM, Remko
Apologies for thinking out loud and not being clear. Code generation can
probably be made to work with either "real" enums or the extensible enums
approach. The mechanism may differ but either should be possible. So from
that point of view, no preference either way. Again apologies for the
confusio
*static Map in the extensible enum class
On Sun, Jan 26, 2014 at 2:56 PM, Remko Popma wrote:
> After thinking about it some more, the code generation could just access
> the static Map in the extensible enums class and find out what instances
> are registered. That would work but assumes that t
After thinking about it some more, the code generation could just access
the static Map in the extensible enums class and find out what instances
are registered. That would work but assumes that the configuration (or at
least the initialization of the static Map in Levels) is complete before
code g
Did you mean that a custom Level implementation cannot extend StdLevel?
So a custom Level implementation would need to include the levels defined
in StdLevel (DEBUG, INFO, ...) in addition to the custom levels.
I think I see now.
How much of a problem is this though? Or, do we need to start thinki
I don't think client code can do new Level(){} as the constructor requires
String and int arguments.
By the way, I am unclear on what went wrong with the enum approach you
originally took.
You said:
StdLevel isn’t a Level because it can’t extend it if it is an enum, so
I can’t initialize the l
Out of curiosity, what exactly is the benefit of declaring the class abstract
when it has a protected constructor? It seems like all you are accomplishing
is making the instantiation syntax uglier. It also bothers me that open code
can just do a new Level(){} - which will do nothing but cause p
Yeah, I missed the {} as I modified the class before I tried to compile it.
You can’t just use an AtomicInteger because you might be adding a duplicate to
the map, in which case you have incorrectly incremented the ordinal. I used
simple synchronization.
Unfortunately, because the extended lev
Ralph,
I copied Nick's code _as is_ and had no compile errors.
The class is abstract, but instances are defined in the static block as:
OFF = new Level("OFF", 0) {}; // note the {}: this creates an anonymous
concrete subclass
I agree that read access needs to be synchronized as well, not just writ
Ralph, if you're getting compile errors with that code, A) there's a
copy-paste/transposition error, or B) there's something wrong with your
(non-standard?) compiler. Given:
abstract class A { ... }
This is perfectly legal in Java 5+:
A a = new A() { };
That's an anonymous inner class extendi
the Logger interface, it was to add
> code to a user's class that wraps a logger.
>
> G
>
>
> Original message
> From: Remko Popma
> Date:01/25/2014 21:51 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Enums and Custom Levels
&
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
My idea was _not_ to add byte codes to the Logger interface, it was to add code
to a user's class that wraps a logger.
G
Original message
From: Remko Popma
Date:01/25/2014 21:51 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Enums and Custom Levels
I'
Yeah, I took another 5 minutes and thought about it. A proxy isn’t the full
answer as somehow we need to create the method signatures for compile time.
I’ve done that before from database data to generate an interface but this is a
little different.
Ralph
On Jan 25, 2014, at 7:07 PM, Remko Po
I mean, not sure whether to use Proxy or generate code or something else,
but hopefully get really close to the ease-of-use of the current Logger
interface...
On Sun, Jan 26, 2014 at 12:06 PM, Remko Popma wrote:
> I'm not sure how close we can get to what we have now, but yes, that was
> what I
I'm not sure how close we can 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
>
> On Jan 2
Wow - I had never thought about using a Java Proxy to implement all those
methods before. That would be a piece of cake.
Ralph
On Jan 25, 2014, at 6:51 PM, Remko Popma wrote:
> I've started to think about how to implement Gary's idea to use these custom
> levels to generate code that would a
Great! That plus support for defining custom levels from the config (with
no custom class required) would mean we would have found a solution that I
believe resolves everyone's issues.
Scott
On Jan 25, 2014 6:52 PM, "Remko Popma" wrote:
> I've started to think about how to implement Gary's idea
I've started to think about how to implement Gary's idea to use these
custom levels to generate code that would add methods to the Logger
interface, but I think I'll wait a little to see what form the custom
levels take.
On Sun, Jan 26, 2014 at 11:45 AM, Remko Popma wrote:
> These are the switc
These are the switches I found:
* log4j-1.2-api: org.apache.log4j.Category - just FYI, it looks like this
switch is missing the FATAL level... is this a bug?
* log4j-api: org.apache.logging.log4j.status.StatusLogger
* log4j-core: org.apache.logging.log4j.core.net.Severity
* log4j-core: org.apache.l
I am not sure what you mean by this. I have already succeeded in adding custom
level names to the configuration and making them be valid. I am just trying to
clean it up a bit based on what Nick is suggesting.
Ralph
On Jan 25, 2014, at 6:30 PM, Scott Deboy wrote:
> There's no way to add sup
Actually, we can use switch in all the places it is currently being used. They
are all places where we are converting between our levels to a Level or
Severity from some other framework. I handled that by first mapping custom
levels to the closest standard level and then using the switch state
There's no way 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:
> The class is needed
You can't "switch" anymore because custom levels means you'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 ext
The class is needed because it is a name and a value (two items) that has to be
represented as a single parameter to Logger methods. Using raw int or String
is not a good alternative.
Ralph
On Jan 25, 2014, at 4:54 PM, Scott Deboy wrote:
> If levels are just a name and a value why require a
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:
Sure, I can take a look at doing it that way. But it is going to have many of
the same problems to implement as to what I just finished doing - except that I
won’t need the Levels class or Levels interface. The one downside to this
approach is that there are 4 or 5 places where Level is used in
Nick, I think because your solution is considered "old style" enums. I
don't know anyone making those kind of enums anymore since JDK 1.5 gave us
an official "enum" keyword. Using that and interfaces is preferred, I think.
On Sat, Jan 25, 2014 at 7:32 PM, Nicholas Williams <
nicho...@nicholaswill
I actually do object I think. It sounds like a significantly more convoluted
approach than the extensible enum. With the extensible enum, new levels are
immediately discovered, serialization works automatically, and extenders don't
have to do any extra work in the constructor. Why are we making
In any event, I'd like to thank the entire Log4J Developer community here
for hearing out my interface idea without biting my head off -- after all,
it's a "big" change near a GA release :-) It was also nice knowing there
exists a place where a serious technical debate can remain cordial. Kudos.
An
If levels are just a name and a value why require 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
>
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.logging.test.ExtendedLevel.DIAG”.
In any case I fixed it. I just annotated the new Level as a Plugin and then
look up all the Level plugins in BaseConfiguratio
Would it be an option to require that the custom level class package is
mentioned in the Configuration packages="..." attribute?
On Sun, Jan 26, 2014 at 9:26 AM, Paul Benedict wrote:
> If you made it a requirement for the constructor to register, why not just
> instantiate each level as you enc
If you made it a requirement for the constructor to register, why not just
instantiate each level as you encounter it in the config?
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
1 - 100 of 133 matches
Mail list logo
