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
I completely agree.
On Sunday, January 26, 2014, Gary Gregory garydgreg...@gmail.com wrote:
It does not matter how rare you think a condition will be, with
concurrency issues, it's will happen, so we should only consider bug free
solutions.
Gary
Original message
From:
[
https://issues.apache.org/jira/browse/LOG4J2-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Devenish updated LOG4J2-316:
--
Attachment: Log4j-circular-more.svg
Log4j-circular-more.png
Logo Contest
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,
Wolf480 Pl created LOG4J2-514:
-
Summary: ConsoleAppender closing System.out on Windows
Key: LOG4J2-514
URL: https://issues.apache.org/jira/browse/LOG4J2-514
Project: Log4j 2
Issue Type: Bug
[
https://issues.apache.org/jira/browse/LOG4J2-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wolf480 Pl updated LOG4J2-514:
--
Description:
If the Console appender is not specified in the configuration file, after the
[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reopened LOG4J2-41:
---
Assignee: Ralph Goers
Reopening as we agreed to address this.
Extensible Log Level
[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers closed LOG4J2-41.
-
Extensible Log Level
Key: LOG4J2-41
URL:
[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers resolved LOG4J2-41.
---
Resolution: Fixed
Fix Version/s: 2.0-rc1
Support for custom levels was added in revision
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
[
https://issues.apache.org/jira/browse/LOG4J2-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882421#comment-13882421
]
Matt Sicker commented on LOG4J2-373:
I meant log4j-core, not osgi.
Classloader issue
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,
Nick, Are you working on this?
Ralph
On Jan 18, 2014, at 11:38 AM, Nicholas Williams nicho...@nicholaswilliams.net
wrote:
Yes. Next weekend I plan on adding a Servlet context parameter that allows
the user to disable starting Log4j automatically. That should allow us to
keep everything in
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
Hello everyone,
last thursday i had a small chat with christian grobmeier on a java user group
meeting
i am doing a lot of search and analytics in my daily business and i am very
interessted in developing a component that directly logs into a
solr/elasticsearch index
Over a year ago i allready
I am. Today, in fact.
N
On Jan 26, 2014, at 3:43 PM, Ralph Goers wrote:
Nick, Are you working on this?
Ralph
On Jan 18, 2014, at 11:38 AM, Nicholas Williams
nicho...@nicholaswilliams.net wrote:
Yes. Next weekend I plan on adding a Servlet context parameter that allows
the user to
[
https://issues.apache.org/jira/browse/LOG4J2-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882458#comment-13882458
]
Matt Sicker commented on LOG4J2-513:
So far, one major refactoring that was required
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
The closest existing components that are vaguely related to what you're
requesting are Mongo and CouchDB appenders. In log4j-core, the NoSQL
appenders might be a good place to put this, but I'm not too sure. I mean,
solr is kind of like a database, so it might belong in db at least.
On 26
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
[
https://issues.apache.org/jira/browse/LOG4J2-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-513:
---
Attachment: 0002-Refactor-class-loader-usage-in-LogManager.patch
Matt Sicker created LOG4J2-515:
--
Summary: Support OSGi bundles without requiring OSGi dependencies.
Key: LOG4J2-515
URL: https://issues.apache.org/jira/browse/LOG4J2-515
Project: Log4j 2
Issue
[
https://issues.apache.org/jira/browse/LOG4J2-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882482#comment-13882482
]
Matt Sicker commented on LOG4J2-400:
Linking this to an epic for OSGi support.
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
[
https://issues.apache.org/jira/browse/LOG4J2-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882483#comment-13882483
]
Matt Sicker commented on LOG4J2-461:
This might be a class loader issue if Android
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.
Matt Sicker created LOG4J2-516:
--
Summary: As a developer using OSGi, I want to use Log4J as my OSGi
Log Service
Key: LOG4J2-516
URL: https://issues.apache.org/jira/browse/LOG4J2-516
Project: Log4j 2
Sorry if I misread. Any mechanism that supports custom levels and gets as
close as possible to the ease of use of the built-in logger interface is
fine with me.
On Monday, January 27, 2014, Gary Gregory garydgreg...@gmail.com wrote:
Please read my message again. I talk about wrapping not
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:
[
https://issues.apache.org/jira/browse/LOG4J2-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Devenish updated LOG4J2-316:
--
Attachment: Log4j-rectangular.svg
Log4j-rectangular.png
Attached rectangular
Sorry. Your message could not be delivered to:
internet,PackerCollegiate (The name was not found at the remote site.
Check that the name has been entered correctly.)
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
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
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 ralph.go...@dslextreme.com wrote:
I modified Level to be final and have a private constructor. I added a
static
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,
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 remko.po...@gmail.com wrote:
The switch in o.a.l.Category.getEffectiveLevel() in log4j-1.2-api is missing
the FATAL
Understood. I can't commit from work but I can fix this when I get home
tonight.
On Monday, January 27, 2014, Ralph Goers ralph.go...@dslextreme.com 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
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
I would like to attend but I’m not sure I can.
Ralph
On Jan 25, 2014, at 11:11 AM, Christian Grobmeier grobme...@gmail.com wrote:
Hi folks,
I would like to remind you ApacheCon is happening in April 2014.
If you would like to submit your talk, now is the chance.
I think it would be
Here's a split-off thread for discussing how we can make using custom levels
easier. Some on the team have expressed a desire to make it even easier. Given
hypothetical custom levels DIAG and NOTE, the following would be nice to have:
logger.note(message);
logger.diag(message);
etc.
We're to
If there is a way to support this strictly through configuration that would
be ideal.
I'm trying to find a way to remove my request for additional built in
levels but through configuration instead of adding them ourselves.
Scott
Scott
On Jan 26, 2014 7:38 PM, Nick Williams
It would not be possible to do this strictly through configuration because the
user needs a compiled interface to code against. Where is that compiled
interface to come from?
Nick
On Jan 26, 2014, at 9:40 PM, Scott Deboy wrote:
If there is a way to support this strictly through configuration
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
The JPA criteria API manages to generate a Foo_ class for the entity class
Foo, and that seems to work out fine.
On 26 January 2014 21:45, Nick Williams nicho...@nicholaswilliams.netwrote:
It would not be possible to do this strictly through configuration because
the user needs a compiled
I am going to have to echo what Nick said. If you can think of a way to make
logger.log(SomeClass.SomeLevel, “hello world”);
work without actually creating SomeClass then please share!
Ralph
On Jan 26, 2014, at 7:45 PM, Nick Williams nicho...@nicholaswilliams.net
wrote:
It would not be
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
[
https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandra Sekhar Kakarla updated LOG4J2-512:
--
Description:
Async servlet (async-supported=true) using with log4j2 breaks the
I actually thought that Nick's idea was the answer to that: users create a
custom interface, something like this:
public interface MyLogger extends Logger {
@LoggingLevel(name=DIAG)
void diag(String message);
// optional other methods
}
They get an instance of this interface by
[
https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandra Sekhar Kakarla updated LOG4J2-512:
--
Affects Version/s: 2.0-beta8
Log4j2 need to support Asynchronous Servlets/
Scott would like users to add a level definition to the logging configuration
and have everything else happen auto-magically. That would happen at run-time
which is a bit late since the methods need to be available at compile time.
I believe Scott said he would be fine if users had to do
Yes, I would like to declare in the config:
Level: NOTICE, value: 232
And in Java code be able to use logger.notice(some message).
But I think that'd require invokedynamic..which would probably
require..javassist/ASM?
I'd be ok with anything that's really close to that :)
Scott
On 1/26/14,
Sure, but what's wrong with the idea?
The user provide their own interface, so that interface exists at compile
time.
The interface uses annotations, so it does not need to explicitly refer to
a custom Level instance. Only the /implementation/ needs to know about the
custom Level instances, and
In addition to the above, we could provide a tool to generate a MyLogger
interface with 14 method signatures for each custom Level name. This would
be an offline tool that users would use only once.
But this tool is optional...
On Monday, January 27, 2014, Remko Popma remko.po...@gmail.com wrote:
Not to rehash this issue, but I wanted to clarify what can be vetoed,
for future reference.
I'm only bringing this up to make it clear, unless there is a
'technical justification', a veto is invalid. In my opinion, there
was no 'technical justification' for requesting removal of the new
levels,
Nick, I thought that you meant that users would provide their own
interface, like this:
public interface MyLogger extends Logger {
@LoggingLevel(name=DIAG)
void diag(String message);
// optional other methods
}
That way, this interface exists at compile time.
On Monday, January 27,
Could we leverage Rhino? :)
Scott
On 1/26/14, Nicholas Williams nicho...@nicholaswilliams.net wrote:
Scott, invokedynamic and javassist...those are all /runtime/ things. The
user needs Logger#notice to be available at compile time. Those are not
compatible.
Nick
Sent from my iPhone, so
Of course, they'd have to use rhino, or something else...which doesn't
help. Where's duck typing when you need it :)
On 1/26/14, Scott Deboy scott.de...@gmail.com wrote:
Could we leverage Rhino? :)
Scott
On 1/26/14, Nicholas Williams nicho...@nicholaswilliams.net wrote:
Scott,
Yes, I was saying that. But, unless I'm misunderstanding, Scott doesn't want
the user to even have to write the interface. He wants them to just configure
it and the interface become available magically. I was pointing out that
there's a disconnect between when the configuration is used
[
https://issues.apache.org/jira/browse/LOG4J2-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-33:
--
Attachment: 0001-Add-Loggable.patch
Here's a patch that's inspired by the Loggable meta-library. I'm
If we go the run-once tool route, then you might as well use annotation
processing. I think it would support everything necessary to generate the
appropriate custom logger class.
On 26 January 2014 23:00, Scott Deboy scott.de...@gmail.com wrote:
Of course, they'd have to use rhino, or
[
https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandra Sekhar Kakarla updated LOG4J2-512:
--
Summary: Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while
I'd like to fix LOG4J-412 and 448, but neither of them are showstoppers IMHO
.
Remko
On Monday, January 27, 2014, Ralph Goers ralph.go...@dslextreme.com wrote:
Since we are having good discussions I would also like to find out what
are blockers to a GA release. My list includes:
1. The fix
90 matches
Mail list logo
