Re: [1/2] logging-log4j2 git commit: LOG4J2-1119 documented RMI GC impact

Thanks for pointing that out. I just checked and verified that all properties are supported in Java 8. On Sat, Sep 12, 2015 at 3:33 PM, Gary Gregory wrote: > Nice docs Remko. I think it would be good to note which Java version the > options applies to since some jvm options are no longer support

[jira] [Comment Edited] (LOG4J2-1116) upgrade to log4j2 causes too frequent minor gc

[ https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14738579#comment-14738579 ] Remko Popma edited comment on LOG4J2-1116 at 9/12/15 6:47 AM: -

Fwd: [1/2] logging-log4j2 git commit: LOG4J2-1119 documented RMI GC impact

Nice docs Remko. I think it would be good to note which Java version the options applies to since some jvm options are no longer supported in Java 8 IIRC. Gary   Original message From: rpo...@apache.org Date: 09/11/2015 23:13 (GMT-08:00) To: comm...@logging.apache.org Subj

[jira] [Resolved] (LOG4J2-1119) Disable JMX by default

[ https://issues.apache.org/jira/browse/LOG4J2-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-1119. - Resolution: Won't Fix > Disable JMX by default > -- > > Key:

[jira] [Commented] (LOG4J2-1119) Disable JMX by default

[ https://issues.apache.org/jira/browse/LOG4J2-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14741920#comment-14741920 ] Remko Popma commented on LOG4J2-1119: - Changes reverted in commit d765fcc. Documentat

Re: Site performance page

Ralph, do you know what the numbers in the Advanced Filtering section of the Performance page mean and how they were generated? On Wed, Sep 9, 2015 at 8:35 AM, Remko Popma wrote: > The Performance page http://logging.apache.org/log4j/2.x/performance.html > has a section on Advanced Filtering con

Jenkins build is back to stable : Log4j 2.x #1364

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Jenkins build became unstable: Log4j 2.x #1363

See - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Checkstyle

Actually, I am fine with setters that do that as well. Both can be configured to be OK with the HiddenField element. Ralph > On Sep 11, 2015, at 5:22 PM, Gary Gregory wrote: > > Checkstyle complains about code like this: > > private final int foo; > Ctor(int foo) { > this.foo = foo; > } >

Checkstyle

Checkstyle complains about code like this: private final int foo; Ctor(int foo) { this.foo = foo; } Which is perfectly acceptable IMO. I really do not see the point of renaming all param names in a ctor. In a normal method, yes, you do not want to 'hide' an ivar with a pname. Gary -- E-Mai

Re: LogEvent time API inconsistency

> > On Mon, Sep 7, 2015 at 3:46 AM, Remko Popma wrote: > >> I deliberately chose that name to be consistent with the data source >> (System::nanoTime). >> > Still not liking the new API. Just talkin' : I appreciate your argument that you "chose that name to be consistent with the data source (Sys

Re: AW: org.apache.logging.log4j.core.LifeCycle.State.INITIAL

On Tue, Sep 1, 2015 at 12:29 AM, Remko Popma wrote: > If you want the naming to be consistent, then why not INITIALIZING? > > That gives you > ING and ED for all states. > I like that Remko! TY. Done; in Git master. Gary > > But I'm fine with just INITIAL as well. > > Remko > > Sent from my

Re: AW: org.apache.logging.log4j.core.LifeCycle.State.INITIAL

On Tue, Sep 1, 2015 at 3:50 AM, Ralph Goers wrote: > INITIALIZING makes sense to me > Done; in Git master. Gary > > > Ralph > > On Sep 1, 2015, at 12:29 AM, Remko Popma wrote: > > If you want the naming to be consistent, then why not INITIALIZING? > > That gives you > ING and ED for all stat

[jira] [Resolved] (LOG4J2-1117) OutputStreamManager in ConsoleAppender leaking managers

[ https://issues.apache.org/jira/browse/LOG4J2-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-1117. -- Resolution: Fixed Fix Version/s: 2.4 Thank you for your report and digging into the code

[jira] [Updated] (LOG4J2-1117) OutputStreamManager in ConsoleAppender leaking managers

[ https://issues.apache.org/jira/browse/LOG4J2-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-1117: - Summary: OutputStreamManager in ConsoleAppender leaking managers (was: OutputStreamManager in Co

Re: Security Permissions

Ah, so you are talking about doing this for all of Log4j, not just something we are missing in log4j-jul? Gary On Fri, Sep 11, 2015 at 4:32 PM, Ralph Goers wrote: > j.u.l.LogManager checks LoggingPermission(“control”) on > addPropertyChangeListener, removePropertyChangeListener, readConfigurati

[jira] [Assigned] (LOG4J2-1117) OutputStreamManager in ConsoleAppender leaking managers?

[ https://issues.apache.org/jira/browse/LOG4J2-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reassigned LOG4J2-1117: Assignee: Gary Gregory > OutputStreamManager in ConsoleAppender leaking managers? > --

Re: Security Permissions

j.u.l.LogManager checks LoggingPermission(“control”) on addPropertyChangeListener, removePropertyChangeListener, readConfiguration, reset, and checkAccess. j.u.l.Logger checks LoggingPermission(“control”) on setFilter, addHandler, removeHandler, setUseParentHandlers, and setParent. j.u.l.Memory

Re: Security Permissions

The last time I looked at that it looked like we were doing the right thing. But we might be talking about a different part of the code. Can you be more specific? Gary On Fri, Sep 11, 2015 at 1:55 PM, Ralph Goers wrote: > I was noticing the other day in the jul javadoc that operations that > m

Security Permissions

I was noticing the other day in the jul javadoc that operations that modify the configuration check the security manager for a LoggingPermission. Any thoughts on whether we should also be checking the same permissions? Ralph -