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
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
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 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.
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
56 matches
Mail list logo
