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

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

Re: Slf4j & (legacy?) best practices

The only dependencies I ever end up having to exclude are log4j 1.2 and logback, but that's normally from internal projects not having a consistent logging configuration yet. I've made a PR to spring to update their docs to recommend log4j 2 instead of 1.x:

Re: Slf4j & (legacy?) best practices

One complaint I keep seeing is that libraries coding to the Log4j2 API would somehow result in problems with dependency configuration. I have been fairly isolated from such kind of problems so I don't understand when this could happen and what might cause it. The only hint I got was a brief r

Re: Slf4j & (legacy?) best practices

I've been seeing your posts on /r/java which could help spark some discussions. :) On 14 January 2017 at 22:57, Remko Popma wrote: > Another one along similar lines: "10 Log4j2 API features not in SLF4J" > http://stackoverflow.com/a/41635246/1446916 > > :-) > Remko > > Sent from my iPhone > > On

Re: Github integration set up: logging--log4j-boot.git

It appears that this repository has been successfully deleted now. On 10 January 2017 at 20:30, Gary Gregory wrote: > That repo name is not right :-( > > G > > -- Forwarded message -- > From: > Date: Tue, Jan 10, 2017 at 6:30 PM > Subject: Github integration set up: logging--log

Re: Slf4j & (legacy?) best practices

Another one along similar lines: "10 Log4j2 API features not in SLF4J" http://stackoverflow.com/a/41635246/1446916 :-) Remko Sent from my iPhone > On Jan 13, 2017, at 14:15, Matt Sicker wrote: > > Jira is down right now, but I have this RFC: > https://github.com/apache/logging-log4j-boot >

[jira] [Resolved] (LOG4J2-1776) log4j-boot pom modules for dependency management

[ https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1776. - Resolution: Fixed Assignee: Matt Sicker All the modules in that list have been added. > lo

[jira] [Commented] (LOG4J2-1776) log4j-boot pom modules for dependency management

[ https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823038#comment-15823038 ] Matt Sicker commented on LOG4J2-1776: - As mentioned on the mailing lists, log4j-boot-

Re: Log4j Boot

I've added a version "boot-1.0-alpha1" to JIRA. I'd imagine that any independently versioned subprojects of Log4j can do similarly. I'm thinking there will be at least one alpha release before a 1.0 release candidate. There may be a need for a beta release, but that remains to be seen as most of t

[jira] [Updated] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot

[ https://issues.apache.org/jira/browse/LOG4J2-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1785: Fix Version/s: boot-1.0-alpha1 > Add Spring Boot integration to Log4j Boot > --

[jira] [Closed] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot

[ https://issues.apache.org/jira/browse/LOG4J2-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1785. --- Closing with fix version set. > Add Spring Boot integration to Log4j Boot >

[jira] [Reopened] (LOG4J2-1778) Add logging-log4j-boot git repo

[ https://issues.apache.org/jira/browse/LOG4J2-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reopened LOG4J2-1778: - Reopening to set fix version. > Add logging-log4j-boot git repo > --- >

[jira] [Updated] (LOG4J2-1776) log4j-boot pom modules for dependency management

[ https://issues.apache.org/jira/browse/LOG4J2-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1776: Fix Version/s: boot-1.0-alpha1 > log4j-boot pom modules for dependency management > ---

[jira] [Closed] (LOG4J2-1778) Add logging-log4j-boot git repo

[ https://issues.apache.org/jira/browse/LOG4J2-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1778. --- Resolution: Fixed Fix Version/s: boot-1.0-alpha1 Marking with fix version. > Add logging-log4

[jira] [Updated] (LOG4J2-1777) Add JUnit categories to integration tests for use in log4j-boot module test suites

[ https://issues.apache.org/jira/browse/LOG4J2-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1777: Fix Version/s: boot-1.0-alpha1 > Add JUnit categories to integration tests for use in log4j-boot mo

[jira] [Updated] (LOG4J2-1783) Add site config for Log4j Boot

[ https://issues.apache.org/jira/browse/LOG4J2-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1783: Fix Version/s: boot-1.0-alpha1 > Add site config for Log4j Boot > -- >

[jira] [Commented] (LOG4J2-1783) Add site config for Log4j Boot

[ https://issues.apache.org/jira/browse/LOG4J2-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823031#comment-15823031 ] Matt Sicker commented on LOG4J2-1783: - I've added a minimal site config so far. Still

Re: Any opposition to requesting git->jira integration?

Sounds like a good idea to me. Remko Sent from my iPhone > On Jan 15, 2017, at 12:26, Apache wrote: > > Fine by me. > > Ralph > >> On Jan 14, 2017, at 8:19 PM, Matt Sicker wrote: >> >> http://apache.org/dev/svngit2jira.html >> >> Basically, this would work similarly to how the current Gi

[jira] [Commented] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823030#comment-15823030 ] Charles Hache commented on LOG4J2-1784: --- Thanks for the prompt replies! Changing t

Re: Any opposition to requesting git->jira integration?

Fine by me. Ralph > On Jan 14, 2017, at 8:19 PM, Matt Sicker wrote: > > http://apache.org/dev/svngit2jira.html > > > Basically, this would work similarly to how the current GitHub integration > works where comments made on pull requests get cross-post

[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823016#comment-15823016 ] Ralph Goers edited comment on LOG4J2-1784 at 1/15/17 3:25 AM: -

Any opposition to requesting git->jira integration?

http://apache.org/dev/svngit2jira.html Basically, this would work similarly to how the current GitHub integration works where comments made on pull requests get cross-posted to jira. This other integration would cross-post commits that make jira references since we don't use Bitbucket or anything

[jira] [Assigned] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers reassigned LOG4J2-1784: --- Assignee: Ralph Goers > Large values for max in DefaultRolloverStrategy blocks application >

[jira] [Updated] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ralph Goers updated LOG4J2-1784: Issue Type: Improvement (was: Bug) > Large values for max in DefaultRolloverStrategy blocks applic

Re: logging-log4j2 git commit: LOG4J2-1748 and LOG4J2-1780 Remove ExecutorServices from LoggerContext

On item 3, the main benefit of an ExecutorService is that the threads are managed and don’t have to be created for each and every task. If the task runs repeatedly, as might happen on a busy system with a max file size and lots of logging going on, this can be beneficial. But when something run

Re: logging-log4j-boot git commit: Add log4j-boot-spring module

In Spring Boot, Tomcat is on the same classpath as everything else I think as it's embedded. On 14 January 2017 at 20:30, Apache wrote: > I have run into problems with log4j-jul. It does not work well in Tomcat > as the jar really has to be in Tomcat’s classpath, which means all the > other log4

Re: logging-log4j2 git commit: LOG4J2-1748 and LOG4J2-1780 Remove ExecutorServices from LoggerContext

Item 1 - this is not a big deal to me, I just noticed it. I can understand Mikael's reasoning that keeping this service would encourage contributors to schedule tasks on non-daemon threads and we need to be judicious about that. Item 2 - ConfigurationScheduler's design, which avoids starting the ba

Re: logging-log4j-boot git commit: Add log4j-boot-spring module

I have run into problems with log4j-jul. It does not work well in Tomcat as the jar really has to be in Tomcat’s classpath, which means all the other log4j jars also need to be. It also has to initialize before Tomcat starts using java.util.logging, which is a bit of a pain. I don’t think there

[jira] [Closed] (LOG4J2-1786) ConfigurationScheduler should preserve interrupt flag during stop

[ https://issues.apache.org/jira/browse/LOG4J2-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-1786. --- Resolution: Fixed Fixed in master in commit 1f06ca4. > ConfigurationScheduler should preserve interr

Re: logging-log4j2 git commit: LOG4J2-1748 and LOG4J2-1780 Remove ExecutorServices from LoggerContext

Item 1 - It should not be removed. Item 2 - The RollingFileAppender could increment the scheduled items if an instance is configured. Ideally, it should only increment it once. Item 3 - It might make more sense for the RollingFileManager to use a ThreadPoolExecutorService that it owns for the as

[jira] [Updated] (LOG4J2-1786) ConfigurationScheduler should preserve interrupt flag during stop

[ https://issues.apache.org/jira/browse/LOG4J2-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma updated LOG4J2-1786: Summary: ConfigurationScheduler should preserve interrupt flag during stop (was: ConfigurationSche

[jira] [Created] (LOG4J2-1786) ConfigurationScheduler should preserve interrupt flag during shutdown

Remko Popma created LOG4J2-1786: --- Summary: ConfigurationScheduler should preserve interrupt flag during shutdown Key: LOG4J2-1786 URL: https://issues.apache.org/jira/browse/LOG4J2-1786 Project: Log4j 2

[jira] [Resolved] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot

[ https://issues.apache.org/jira/browse/LOG4J2-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-1785. - Resolution: Fixed Added to master. Not going to close until I have proper fix versions set for B

[jira] [Created] (LOG4J2-1785) Add Spring Boot integration to Log4j Boot

Matt Sicker created LOG4J2-1785: --- Summary: Add Spring Boot integration to Log4j Boot Key: LOG4J2-1785 URL: https://issues.apache.org/jira/browse/LOG4J2-1785 Project: Log4j 2 Issue Type: New Fea

Fwd: logging-log4j-boot git commit: Add log4j-boot-spring module

So would it be a decent idea to add a similar extended LoggerContextFactory to log4j-jul so it auto sets up in other environments? I find that specifying the system property at the right time in code is very difficult to get right, and the reason this worked well enough with spring boot was because

[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822991#comment-15822991 ] Remko Popma edited comment on LOG4J2-1784 at 1/14/17 11:32 PM:

[jira] [Commented] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822991#comment-15822991 ] Remko Popma commented on LOG4J2-1784: - During the rollover Log4j2 will log what it's

[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822945#comment-15822945 ] Charles Hache edited comment on LOG4J2-1784 at 1/14/17 8:29 PM: ---

[jira] [Comment Edited] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822945#comment-15822945 ] Charles Hache edited comment on LOG4J2-1784 at 1/14/17 8:28 PM: ---

[jira] [Commented] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

[ https://issues.apache.org/jira/browse/LOG4J2-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15822945#comment-15822945 ] Charles Hache commented on LOG4J2-1784: --- My config might be useful...:

[jira] [Created] (LOG4J2-1784) Large values for max in DefaultRolloverStrategy blocks application

Charles Hache created LOG4J2-1784: - Summary: Large values for max in DefaultRolloverStrategy blocks application Key: LOG4J2-1784 URL: https://issues.apache.org/jira/browse/LOG4J2-1784 Project: Log4j 2

Re: logging-log4j2 git commit: LOG4J2-1748 and LOG4J2-1780 Remove ExecutorServices from LoggerContext

Answers to Remkos feedback: 1. I don’t think we should use non-daemon threads in production code, and I don’t think we should pollute production code with stuff only needed by unit tests (unless it makes it a lot easier to do the unit test, which is not the case here). 2. I

[jira] [Updated] (LOG4J2-1783) Add site config for Log4j Boot

[ https://issues.apache.org/jira/browse/LOG4J2-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker updated LOG4J2-1783: Description: Add necessary maven-site-plugin configuration to get a multimodule site buildable cor

[jira] [Created] (LOG4J2-1783) Add site config for Log4j Boot

Matt Sicker created LOG4J2-1783: --- Summary: Add site config for Log4j Boot Key: LOG4J2-1783 URL: https://issues.apache.org/jira/browse/LOG4J2-1783 Project: Log4j 2 Issue Type: Documentation

Re: Log4j Boot

I've started it at 1.0-SNAPSHOT based on 2.7.1-SNAPSHOT, though log4j-boot 1.0 wouldn't come out until after 2.8 is tagged most likely. I'm not sure about an alpha release yet. On 12 January 2017 at 23:22, Matt Sicker wrote: > Although a version number property could be used, too, with appropria

Jenkins build became unstable: Log4j 2.x #2595

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

[jira] [Created] (LOG4J2-1782) Upgrade to JCTools from 1.2.1 to 2.0.1

Matt Sicker created LOG4J2-1782: --- Summary: Upgrade to JCTools from 1.2.1 to 2.0.1 Key: LOG4J2-1782 URL: https://issues.apache.org/jira/browse/LOG4J2-1782 Project: Log4j 2 Issue Type: Dependency

[jira] [Closed] (LOG4J2-1781) Update Conversant Disruptor from 1.2.7 to 1.2.10

[ https://issues.apache.org/jira/browse/LOG4J2-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-1781. --- Resolution: Fixed Added to master. > Update Conversant Disruptor from 1.2.7 to 1.2.10 >

[jira] [Created] (LOG4J2-1781) Update Conversant Disruptor from 1.2.7 to 1.2.10

Matt Sicker created LOG4J2-1781: --- Summary: Update Conversant Disruptor from 1.2.7 to 1.2.10 Key: LOG4J2-1781 URL: https://issues.apache.org/jira/browse/LOG4J2-1781 Project: Log4j 2 Issue Type: