Re: Broken build

Hooray, we've finally figured out the bug. :) On 3 May 2014 19:49, Remko Popma wrote: > I just updated from SVN and all tests now pass. > The build works now. Thanks! > > > On Sun, May 4, 2014 at 7:55 AM, Matt Sicker wrote: > >> I just fixed it in r1592291 haha >> >> >> On 3 May 2014 17:54, Ra

Re: Broken build

I just updated from SVN and all tests now pass. The build works now. Thanks! On Sun, May 4, 2014 at 7:55 AM, Matt Sicker wrote: > I just fixed it in r1592291 haha > > > On 3 May 2014 17:54, Ralph Goers wrote: > >> Yes. It cause them to close. Anything written to System.out or System.err >> wil

Re: Broken build

I just fixed it in r1592291 haha On 3 May 2014 17:54, Ralph Goers wrote: > Yes. It cause them to close. Anything written to System.out or System.err > will fail. > > On May 3, 2014, at 3:51 PM, Matt Sicker wrote: > > Does closing them do anything? > > > On 3 May 2014 17:10, Ralph Goers wrote:

Re: Broken build

Yes. It cause them to close. Anything written to System.out or System.err will fail. On May 3, 2014, at 3:51 PM, Matt Sicker wrote: > Does closing them do anything? > > > On 3 May 2014 17:10, Ralph Goers wrote: > Perhaps we need a StatusFileListerner when writing to a file? > > Ralph > > O

Re: Broken build

Never mind. I am fixing it. Ralph On May 3, 2014, at 3:10 PM, Ralph Goers wrote: > Perhaps we need a StatusFileListerner when writing to a file? > > Ralph > > On May 3, 2014, at 3:03 PM, Ralph Goers wrote: > >> System.out or System.err should never be closed. >> >> Ralph >> >> On May 3, 2

Re: Broken build

Does closing them do anything? On 3 May 2014 17:10, Ralph Goers wrote: > Perhaps we need a StatusFileListerner when writing to a file? > > Ralph > > On May 3, 2014, at 3:03 PM, Ralph Goers > wrote: > > System.out or System.err should never be closed. > > Ralph > > On May 3, 2014, at 10:59 AM,

Re: Broken build

Perhaps we need a StatusFileListerner when writing to a file? Ralph On May 3, 2014, at 3:03 PM, Ralph Goers wrote: > System.out or System.err should never be closed. > > Ralph > > On May 3, 2014, at 10:59 AM, Matt Sicker wrote: > >> I've implemented Closeable on StatusListener in r1592258.

Re: Broken build

System.out or System.err should never be closed. Ralph On May 3, 2014, at 10:59 AM, Matt Sicker wrote: > I've implemented Closeable on StatusListener in r1592258. Please try out the > unit tests again and let me know if this solves the issue on Windows. > > > On 3 May 2014 12:30, Matt Sicker

Re: We need a 2.1 version in JIRA.

Done. Ralph On May 3, 2014, at 11:03 AM, Matt Sicker wrote: > I can't add it myself. > > -- > Matt Sicker

Re: Should we do a feature freeze for 2.0?

I’d like to see web moved to its own subproject. I have a few bugs I want to fix. I’d like to do the rc2 release next weekend if we can. I am hoping this is the last rc. Ralph On May 3, 2014, at 2:29 PM, Matt Sicker wrote: > Sounds good. Any other features we'd like to put in? I think tha

Re: Should we do a feature freeze for 2.0?

Sounds good. Any other features we'd like to put in? I think that was the last major one being worked on at this point. On 3 May 2014 16:07, Gary Gregory wrote: > FYI I have been working on and off on the XML and JSON receivers which > affects the respective layouts. These should be in 2.0. I h

RE: Should we do a feature freeze for 2.0?

FYI I have been working on and off on the XML and JSON receivers which affects the respective layouts. These should be in 2.0. I hope to be done this week or the next. Gary Original message From: Matt Sicker Date:05/03/2014 13:56 (GMT-05:00) To: Log4J Developers List Sub

[jira] [Created] (LOG4J2-630) Add some basic integration tests for various containers.

Matt Sicker created LOG4J2-630: -- Summary: Add some basic integration tests for various containers. Key: LOG4J2-630 URL: https://issues.apache.org/jira/browse/LOG4J2-630 Project: Log4j 2 Issue Ty

We need a 2.1 version in JIRA.

I can't add it myself. -- Matt Sicker

Re: Broken build

I've implemented Closeable on StatusListener in r1592258. Please try out the unit tests again and let me know if this solves the issue on Windows. On 3 May 2014 12:30, Matt Sicker wrote: > I think this is actually a bug. StatusListener should implement Closeable, > and when the listeners are cl

Should we do a feature freeze for 2.0?

In order to get 2.0 GA out the door soon, I think it would be a good idea to freeze new feature additions and focus on bugs and any remaining API changes that might be necessary (if there are any). The experimental branch could be renamed to 2.1.x, or we could start a 2.0.x branch from the current

Re: Broken build

I think this is actually a bug. StatusListener should implement Closeable, and when the listeners are cleared, it should loop through and close them before clearing the list of listeners. Otherwise, files can stay opened and Windows still hasn't figured out how to handle that. On 3 May 2014 11:22

Re: Broken build

Better: add @Ignore next to @Test. Gary Original message From: Remko Popma Date:05/03/2014 12:22 (GMT-05:00) To: Log4J Developers List Subject: Re: Broken build Thanks, commenting out that test to verify my changes was exactly what I was doing now... :-) On Sun, May 4

[jira] [Resolved] (LOG4J2-628) Cannot set log4j.Clock with Async appender

[ https://issues.apache.org/jira/browse/LOG4J2-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma resolved LOG4J2-628. Resolution: Fixed Fix Version/s: 2.0-rc2 Fixed in revision 1592242. The Clock interface is

Re: Broken build

Thanks, commenting out that test to verify my changes was exactly what I was doing now... :-) On Sun, May 4, 2014 at 1:20 AM, Ralph Goers wrote: > > Oh, and if you are trying to do some work just comment out the @Test of > the failing test - but don’t commit that. > > Ralph > > > > On May 3, 20

Re: Broken build

Oh, and if you are trying to do some work just comment out the @Test of the failing test - but don’t commit that. Ralph On May 3, 2014, at 9:19 AM, Ralph Goers wrote: > That happens because the file is still being referenced by something when it > is trying to delete it. It should be becau

Re: Broken build

That happens because the file is still being referenced by something when it is trying to delete it. It should be because the file is open but I recall reading that Windows sometimes holds on to file references longer than it should. This was probably caused by the changes Matt made to the uni

Re: Broken build

Yes, windows 7. On Sun, May 4, 2014 at 12:54 AM, Ralph Goers wrote: > FileOutputTest was failing for me last week and I thought I fixed it. But > it was failing because the file was empty, not because it couldn’t be > deleted. I guess you must be running on Windows? > > Ralph > > On May 3, 2014,

Re: Broken build

FileOutputTest was failing for me last week and I thought I fixed it. But it was failing because the file was empty, not because it couldn’t be deleted. I guess you must be running on Windows? Ralph On May 3, 2014, at 8:44 AM, Remko Popma wrote: > When I run mvn clean install, I get this prob

[jira] [Reopened] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour

[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma reopened LOG4J2-629: > Document the system properties that can be used to modify Log4j 2's behaviour > -

[jira] [Comment Edited] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour

[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13988715#comment-13988715 ] Remko Popma edited comment on LOG4J2-629 at 5/3/14 3:52 PM: Fi

[jira] [Closed] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour

[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-629. -- Resolution: Fixed > Document the system properties that can be used to modify Log4j 2's behaviour > ---

Broken build

When I run mvn clean install, I get this problem: Failed tests: FileOutputTest.testConfig Could not delete target\status.log, last modifed 14/05/04 0:27 FileOutputTest has a "CleanFiles" rule that seems to fail: public RuleChain rules = RuleChain.outerRule(new CleanFiles(STATUS_LOG)).around

[jira] [Closed] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour

[ https://issues.apache.org/jira/browse/LOG4J2-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remko Popma closed LOG4J2-629. -- Resolution: Fixed Fixed in revision 1592221. > Document the system properties that can be used to modi

Re: Use log4j.Clock for timestamping all log events?

Thanks for the explanation. I'll update the descriptions. I raised LOG4J2-629 for this and I'll commit the doc change shortly. Feedback welcome! I'll go and remove the third property together with the default constructor for StatusConsoleListener.

Re: Use log4j.Clock for timestamping all log events?

There are actually 2 levels which is probably why this is so confusing. One applies to the status logger, which is only used when there are no listeners and controls what is saved in the buffer. The second is for the status console listener, which filters what should be written to the console fr

[jira] [Created] (LOG4J2-629) Document the system properties that can be used to modify Log4j 2's behaviour

Remko Popma created LOG4J2-629: -- Summary: Document the system properties that can be used to modify Log4j 2's behaviour Key: LOG4J2-629 URL: https://issues.apache.org/jira/browse/LOG4J2-629 Project: Log4

Re: Use log4j.Clock for timestamping all log events?

While documenting the system properties I found there are three(!) system properties related to the default status logger level. And they all have a different default value... 1. log4j2.StatusLogger.level (default: WARN) - the StatusLogger level 2. Log4jDefaultStatusLevel (default: ERROR) - used i