logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <rgo...@apache.org>
Subject Re: Broken build
Date Sun, 04 May 2014 17:40:03 GMT
That is what I was doing yesterday before I got your "haha" email.

Ralph

> On May 4, 2014, at 9:53 AM, Matt Sicker <boards@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 <rgoers@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.brouwer@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 <boards@gmail.com> wrote:
>>>> Hooray, we've finally figured out the bug. :)
>>>> 
>>>> 
>>>>> On 3 May 2014 19:49, Remko Popma <remko.popma@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 <boards@gmail.com>
wrote:
>>>>>> I just fixed it in r1592291 haha
>>>>>> 
>>>>>> 
>>>>>>> On 3 May 2014 17:54, Ralph Goers <ralph.goers@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 <boards@gmail.com>
wrote:
>>>>>>>> 
>>>>>>>> Does closing them do anything?
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 3 May 2014 17:10, Ralph Goers <ralph.goers@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.goers@dslextreme.com>
wrote:
>>>>>>>>>> 
>>>>>>>>>> System.out or System.err should never be closed.
>>>>>>>>>> 
>>>>>>>>>> Ralph
>>>>>>>>>> 
>>>>>>>>>>> On May 3, 2014, at 10:59 AM, Matt Sicker <boards@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 <boards@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.popma@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.goers@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.goers@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.popma@gmail.com> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Yes, windows 7.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Sun, May 4, 2014 at
12:54 AM, Ralph Goers <ralph.goers@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.popma@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-unsubscribe@logging.apache.org
>>>>>>>>>>>>>>>>> For additional commands,
e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Matt Sicker <boards@gmail.com>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> Matt Sicker <boards@gmail.com>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Matt Sicker <boards@gmail.com>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Matt Sicker <boards@gmail.com>
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Matt Sicker <boards@gmail.com>
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> Bruce Brouwer
> 
> 
> 
> -- 
> Matt Sicker <boards@gmail.com>

Mime
View raw message