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, at 9:51
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 remko.po...@gmail.com wrote:
Who will make this change (getOrCreateLevel - forName) ?
I'm asking because I'm calling this method in the generated
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
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, writing
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 nicho...@nicholaswilliams.net
wrote:
Wrapping a logger /implementation/ is fine. But the user needs an /interface/
to program
Yes that's the idea.
Gary
Original message
From: Ralph Goers ralph.go...@dslextreme.com
Date:01/27/2014 11:19 (GMT-05:00)
To: Log4J Developers List log4j-dev@logging.apache.org
Subject: Re: Enums and Custom Levels - completed.
If the user creates a custom Logger Wrapper
(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?
Ralph
On Jan 27, 2014, at 6:40 AM, Nick Williams nicho...@nicholaswilliams.net
I'm very curious! Can't wait to see it. Go for it!
On Sunday, January 26, 2014, Ralph Goers ralph.go...@dslextreme.com 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
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 ralph.go...@dslextreme.com wrote:
I have completed the work on custom levels. It uses a variation of
Nick’s
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,
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
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
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 remko.po...@gmail.com wrote:
I'm very curious! Can't wait to see it. Go for
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,
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 ralph.go...@dslextreme.com wrote:
I haven’t done anything to
Some (ok, a lot of) feedback:
- `private static ConcurrentMapString, Level 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
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,
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
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
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
+1 to everything Nick said.
On 26 January 2014 16:40, Nick Williams nicho...@nicholaswilliams.netwrote:
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
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
By the way, there may be a small concurrency bug in the Level.values()
static method. This may be better:
public static Level[] values() {
CollectionLevel values = Level.levels.values();
return values.toArray(new Level[values.size()]); // use value
collection size, not map
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:
Yes that's what I was thinking.
Scott
On Jan 26, 2014 3:18 PM, Remko Popma remko.po...@gmail.com 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
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.
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.
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
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 nicho...@nicholaswilliams.net
wrote:
I would be OK with getting rid of the
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 boa...@gmail.com wrote:
Don't annotation processing plugins work well in IDEs? Either way,
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
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 T
extends EnumT Level generic, too, right?
On 26 January 2014 18:14, Ralph Goers ralph.go...@dslextreme.com wrote:
Oh, actually I used an Interface for
Please read my message again. I talk about wrapping not extending.
Gary
Original message
From: Remko Popma remko.po...@gmail.com
Date:01/26/2014 18:17 (GMT-05:00)
To: Log4J Developers List log4j-dev@logging.apache.org
Subject: Re: Enums and Custom Levels - completed
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 that based on user-specified custom
levels, we would generate
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
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 ralph.go...@dslextreme.com wrote:
I am
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
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,
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
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 scott.de...@gmail.com wrote:
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 ralph.go...@dslextreme.com wrote:
I think I must be misunderstanding the part about “If those levels were
added…”. I don’t understand
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,
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
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
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 ralph.go...@dslextreme.comwrote:
Yes, logger.log(MyCustomLEvels.LEVEL1, “message”); works right now. See
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,
How about Level.forName()?
On 26 January 2014 21:06, Ralph Goers ralph.go...@dslextreme.com 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
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 what
I second my suggestion!
On 26 January 2014 21:44, Ralph Goers ralph.go...@dslextreme.com 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
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 nicho...@nicholaswilliams.netwrote:
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
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
51 matches
Mail list logo
