That is what I was doing yesterday before I got your "haha" email.
Ralph > On May 4, 2014, at 9:53 AM, Matt Sicker <boa...@gmail.com> wrote: > > So how about adding a check at construction checking against System.out and > System.err? Really, once you start messing with those streams, you can't be > sure they'll ever be closed until the JVM stops or you manually close it. > > >> On 4 May 2014 09:36, Ralph Goers <rgo...@apache.org> wrote: >> I see two choices here - maintain a use count or just let the OS close the >> files. >> >> The second would be pretty easy to do once we move the web stuff to its own >> module as it can add a property that the console Appender would look for. >> >> The first option is probably better if it could be made to work properly. >> >> Ralph >> >>> On May 4, 2014, at 6:38 AM, Bruce Brouwer <bruce.brou...@gmail.com> wrote: >>> >>> This is what I was starting to investigate with LOG4J2-609. >>> >>> I don't think this is quite there yet. For one, in >>> StatusConsoleListener.close(), System.out and System.err can change over >>> time, so doing the != check might still close something that at one time >>> was System.out but no longer is. >>> >>> Also, a StatusConsoleListener is shared among different JSONConfiguration >>> and XMLConfiguration instances (think about multiple WARs in a Tomcat >>> instance where log4j is in Tomcat's shared lib directory). If we undeployed >>> one of those WARs, it would shutdown the StatusConsoleListener that was >>> shared with the other WAR deployments. >>> >>> Also think about where some of these WARs wanted to use System.out and >>> others want to use a log file for status logging. Because of the way these >>> shared loggers are found, only the first StatusConsoleListener registered >>> would actually take effect. So sometimes when you start Tomcat, status logs >>> go to System.out, other times they go to a log file. I'd hate having to >>> debug that one if I didn't know about this issue. >>> >>> I have an idea of how to address this, but it unfortunately isn't as simple >>> as closing the StatusConsoleListener. >>> >>> >>>> On Sat, May 3, 2014 at 10:04 PM, Matt Sicker <boa...@gmail.com> wrote: >>>> Hooray, we've finally figured out the bug. :) >>>> >>>> >>>>> On 3 May 2014 19:49, Remko Popma <remko.po...@gmail.com> 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 <boa...@gmail.com> wrote: >>>>>> I just fixed it in r1592291 haha >>>>>> >>>>>> >>>>>>> On 3 May 2014 17:54, Ralph Goers <ralph.go...@dslextreme.com> 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 <boa...@gmail.com> wrote: >>>>>>>> >>>>>>>> Does closing them do anything? >>>>>>>> >>>>>>>> >>>>>>>>> On 3 May 2014 17:10, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>>>>>>>> Perhaps we need a StatusFileListerner when writing to a file? >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On May 3, 2014, at 3:03 PM, Ralph Goers <ralph.go...@dslextreme.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> System.out or System.err should never be closed. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>>> On May 3, 2014, at 10:59 AM, Matt Sicker <boa...@gmail.com> 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 <boa...@gmail.com> wrote: >>>>>>>>>>>> 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, Remko Popma <remko.po...@gmail.com> wrote: >>>>>>>>>>>>> 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 >>>>>>>>>>>>>> <ralph.go...@dslextreme.com> 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, 2014, at 9:19 AM, Ralph Goers >>>>>>>>>>>>>>> <ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 unit test >>>>>>>>>>>>>>> framework a month or so ago. I will bring up my Windows VM and >>>>>>>>>>>>>>> take a look at it this afternoon. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On May 3, 2014, at 8:58 AM, Remko Popma >>>>>>>>>>>>>>>> <remko.po...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, windows 7. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sun, May 4, 2014 at 12:54 AM, Ralph Goers >>>>>>>>>>>>>>>>> <ralph.go...@dslextreme.com> 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, at 8:44 AM, Remko Popma >>>>>>>>>>>>>>>>> <remko.po...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > 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(new >>>>>>>>>>>>>>>>> > InitialLoggerContext(CONFIG)); >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > How do I fix this? >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Remko >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>>> To unsubscribe, e-mail: >>>>>>>>>>>>>>>>> log4j-dev-unsubscr...@logging.apache.org >>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>>>> log4j-dev-h...@logging.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >>> -- >>> >>> Bruce Brouwer > > > > -- > Matt Sicker <boa...@gmail.com>
