Re: Broken build
I made that change to log4j-api-test and that fixed the problem. Ralph > On Nov 17, 2022, at 3:29 PM, Piotr P. Karwasz wrote: > > On Thu, 17 Nov 2022 at 23:23, Ralph Goers wrote: >> >> I ran mvn test -Dtest=LoggerTest and it still fails. > > In `release-2.x` JUnit 5 is configured with: > > junit.jupiter.execution.parallel.mode.default = concurrent > > In `master` we have: > > junit.jupiter.execution.parallel.mode.default = same_thread > junit.jupiter.execution.parallel.mode.classes.default = concurrent > > and it seems much more stable. Running all the test methods of a class > concurrently is something we are not ready for. > > Piotr
Re: Broken build
On Thu, 17 Nov 2022 at 23:23, Ralph Goers wrote: > > I ran mvn test -Dtest=LoggerTest and it still fails. In `release-2.x` JUnit 5 is configured with: junit.jupiter.execution.parallel.mode.default = concurrent In `master` we have: junit.jupiter.execution.parallel.mode.default = same_thread junit.jupiter.execution.parallel.mode.classes.default = concurrent and it seems much more stable. Running all the test methods of a class concurrently is something we are not ready for. Piotr
Re: Broken build
I ran mvn test -Dtest=LoggerTest and it still fails. Ralph > On Nov 17, 2022, at 12:27 PM, Matt Sicker wrote: > > There’s a random seed value output for each run as the test order is > randomized. You can use the seed to replay a particular test ordering, though > if it’s a bug, it’ll still likely only show up randomly. > >> On Nov 17, 2022, at 5:23 AM, Gary Gregory wrote: >> >> The stack bottom shows >> >> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) >> >> I hope we are not running tests in parallel or else how can we be reliable >> and reproducible? And compare builds between developers? >> >> Gary >> >> On Wed, Nov 16, 2022, 19:23 Matt Sicker wrote: >> >>> Is this a consistent failure or random? >>> On Nov 16, 2022, at 3:42 PM, Ralph Goers >>> wrote: I haven’t run a build in a while and looking at the recent commits I am >>> not sure what is causing this, but some change since 2.19.0 is now causing >>> the following build failures in log4j-core. Ralph [ERROR] Failures: [ERROR] LoggerTest.basicFlow:90 expected: <2> but was: <4> [ERROR] LoggerTest.builder:77 Incorrect message 1 Expected: " DEBUG >>> org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello" but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)" [ERROR] LoggerTest.debug:209 expected: <1> but was: <0> [ERROR] LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but >>> was: <2> [ERROR] LoggerTest.flowTracingMessage:104 Incorrect Entry Expected: a string starting with "ENTER[ FLOW ] TRACE Enter" but: was "THROWING[ EXCEPTION ] ERROR Throwing >>> java.lang.IllegalArgumentException: Test Exception at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at >>> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at >>> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at >>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at >>> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at >>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at >>> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at >>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at >>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at >>> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at >>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at >>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at >>> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at >>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at >>> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at >>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at >>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at >>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at >>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at >>> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at >>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at >>> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at >>> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at >>> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at >>>
Re: Broken build
There’s a random seed value output for each run as the test order is randomized. You can use the seed to replay a particular test ordering, though if it’s a bug, it’ll still likely only show up randomly. > On Nov 17, 2022, at 5:23 AM, Gary Gregory wrote: > > The stack bottom shows > > java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) > > I hope we are not running tests in parallel or else how can we be reliable > and reproducible? And compare builds between developers? > > Gary > > On Wed, Nov 16, 2022, 19:23 Matt Sicker wrote: > >> Is this a consistent failure or random? >> >>> On Nov 16, 2022, at 3:42 PM, Ralph Goers >> wrote: >>> >>> I haven’t run a build in a while and looking at the recent commits I am >> not sure what is causing this, but some change since 2.19.0 is now causing >> the following build failures in log4j-core. >>> >>> Ralph >>> >>> [ERROR] Failures: >>> [ERROR] LoggerTest.basicFlow:90 expected: <2> but was: <4> >>> [ERROR] LoggerTest.builder:77 Incorrect message 1 >>> Expected: " DEBUG >> org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello" >>>but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)" >>> [ERROR] LoggerTest.debug:209 expected: <1> but was: <0> >>> [ERROR] LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but >> was: <2> >>> [ERROR] LoggerTest.flowTracingMessage:104 Incorrect Entry >>> Expected: a string starting with "ENTER[ FLOW ] TRACE Enter" >>>but: was "THROWING[ EXCEPTION ] ERROR Throwing >> java.lang.IllegalArgumentException: Test Exception >>> at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at >> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) >>> at >> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) >>> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) >>> at >> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) >>> at >> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) >>> at >> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) >>> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) >>> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) >>> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) >>> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) >>> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) >>> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) >>> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) >>> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) >>> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) >>> at >> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) >>> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) >>> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) >>> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) >>> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) >>> at >> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) >>> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) >>> at >> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) >>> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) >>> at >> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) >>> at >>
Re: Broken build
I haven’t tried master recently. The failures I am seeing are in release-2.x. Ralph > On Nov 17, 2022, at 10:23 AM, Piotr P. Karwasz > wrote: > > Hi Gary, > > On Thu, 17 Nov 2022 at 12:24, Gary Gregory wrote: >> I hope we are not running tests in parallel or else how can we be reliable >> and reproducible? And compare builds between developers? > > Yes, `log4j-api-test` is configured to run in parallel (at least in > `master`). This setting has been switched on and off in the past year. > In June I switched it on: > > https://github.com/apache/logging-log4j2/commit/0e68a1ab3c94d7a86a8e85483c2c36d4ff9143b7 > > Build errors in `log4j-api-test` have been rare these last months, but > probably we need a profile to switch parallelism off (or a profile to > switch it on). > > Piotr
Re: Broken build
Hi Gary, On Thu, 17 Nov 2022 at 12:24, Gary Gregory wrote: > I hope we are not running tests in parallel or else how can we be reliable > and reproducible? And compare builds between developers? Yes, `log4j-api-test` is configured to run in parallel (at least in `master`). This setting has been switched on and off in the past year. In June I switched it on: https://github.com/apache/logging-log4j2/commit/0e68a1ab3c94d7a86a8e85483c2c36d4ff9143b7 Build errors in `log4j-api-test` have been rare these last months, but probably we need a profile to switch parallelism off (or a profile to switch it on). Piotr
Re: Broken build
On Windows, I get: [INFO] Running org.apache.logging.log4j.status.StatusConsoleListenerTest [ERROR] Tests run: 41, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042 s <<< FAILURE! - in org.apache.logging.log4j.spi.MutableThreadContextStackTest [ERROR] org.apache.logging.log4j.LoggerTest.flowTracingMessage Time elapsed: 0.48 s <<< FAILURE! org.opentest4j.AssertionFailedError: expected: <2> but was: <3> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528) at org.apache.logging.log4j.LoggerTest.flowTracingMessage(LoggerTest.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185) at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189) at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) at java.util.concurrent.ForkJoinTask.doJoin(ForkJoinTask.java:389) at
Re: Broken build
Consistent Ralph > On Nov 16, 2022, at 5:23 PM, Matt Sicker wrote: > > Is this a consistent failure or random? > >> On Nov 16, 2022, at 3:42 PM, Ralph Goers wrote: >> >> I haven’t run a build in a while and looking at the recent commits I am not >> sure what is causing this, but some change since 2.19.0 is now causing the >> following build failures in log4j-core. >> >> Ralph >> >> [ERROR] Failures: >> [ERROR] LoggerTest.basicFlow:90 expected: <2> but was: <4> >> [ERROR] LoggerTest.builder:77 Incorrect message 1 >> Expected: " DEBUG >> org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello" >>but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)" >> [ERROR] LoggerTest.debug:209 expected: <1> but was: <0> >> [ERROR] LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but was: >> <2> >> [ERROR] LoggerTest.flowTracingMessage:104 Incorrect Entry >> Expected: a string starting with "ENTER[ FLOW ] TRACE Enter" >>but: was "THROWING[ EXCEPTION ] ERROR Throwing >> java.lang.IllegalArgumentException: Test Exception >> at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) >> at >> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) >> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) >> at >> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) >> at >> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) >> at >> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) >> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) >> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) >> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) >> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) >> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) >> at >> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) >> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) >> at >> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) >> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) >> at >> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) >> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) >> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) >> at >> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) >> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) >> at >> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) >> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) >> at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) >> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) >> at >> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) >> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) >> at >> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) >> at >> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185) >> at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189) >> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) >> at >>
Re: Broken build
The stack bottom shows java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) I hope we are not running tests in parallel or else how can we be reliable and reproducible? And compare builds between developers? Gary On Wed, Nov 16, 2022, 19:23 Matt Sicker wrote: > Is this a consistent failure or random? > > > On Nov 16, 2022, at 3:42 PM, Ralph Goers > wrote: > > > > I haven’t run a build in a while and looking at the recent commits I am > not sure what is causing this, but some change since 2.19.0 is now causing > the following build failures in log4j-core. > > > > Ralph > > > > [ERROR] Failures: > > [ERROR] LoggerTest.basicFlow:90 expected: <2> but was: <4> > > [ERROR] LoggerTest.builder:77 Incorrect message 1 > > Expected: " DEBUG > org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello" > > but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)" > > [ERROR] LoggerTest.debug:209 expected: <1> but was: <0> > > [ERROR] LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but > was: <2> > > [ERROR] LoggerTest.flowTracingMessage:104 Incorrect Entry > > Expected: a string starting with "ENTER[ FLOW ] TRACE Enter" > > but: was "THROWING[ EXCEPTION ] ERROR Throwing > java.lang.IllegalArgumentException: Test Exception > > at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) > > at > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) > > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) > > at > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) > > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) > > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) > > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) > > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) > > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) > > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) > > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) > > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) > > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) > > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) > > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) > > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) > > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) > > at > org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) > > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) > > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) > > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) > > at > org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185) > > at
Re: Broken build
Is this a consistent failure or random? > On Nov 16, 2022, at 3:42 PM, Ralph Goers wrote: > > I haven’t run a build in a while and looking at the recent commits I am not > sure what is causing this, but some change since 2.19.0 is now causing the > following build failures in log4j-core. > > Ralph > > [ERROR] Failures: > [ERROR] LoggerTest.basicFlow:90 expected: <2> but was: <4> > [ERROR] LoggerTest.builder:77 Incorrect message 1 > Expected: " DEBUG > org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello" > but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)" > [ERROR] LoggerTest.debug:209 expected: <1> but was: <0> > [ERROR] LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but was: <2> > [ERROR] LoggerTest.flowTracingMessage:104 Incorrect Entry > Expected: a string starting with "ENTER[ FLOW ] TRACE Enter" > but: was "THROWING[ EXCEPTION ] ERROR Throwing > java.lang.IllegalArgumentException: Test Exception > at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) > at > org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) > at > org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) > at > org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) > at > org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) > at > org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) > at > org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) > at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) > at > org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) > at > org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) > at > org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185) > at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189) > at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) > at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) > at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) > at > java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157) >
Broken build
I haven’t run a build in a while and looking at the recent commits I am not sure what is causing this, but some change since 2.19.0 is now causing the following build failures in log4j-core. Ralph [ERROR] Failures: [ERROR] LoggerTest.basicFlow:90 expected: <2> but was: <4> [ERROR] LoggerTest.builder:77 Incorrect message 1 Expected: " DEBUG org.apache.logging.log4j.LoggerTest.builder(LoggerTest.java:73) Hello" but: was "ENTER[ FLOW ] TRACE Enter doFoo(a=1, b=2)" [ERROR] LoggerTest.debug:209 expected: <1> but was: <0> [ERROR] LoggerTest.debugWithParmsAndThrowable:230 expected: <1> but was: <2> [ERROR] LoggerTest.flowTracingMessage:104 Incorrect Entry Expected: a string starting with "ENTER[ FLOW ] TRACE Enter" but: was "THROWING[ EXCEPTION ] ERROR Throwing java.lang.IllegalArgumentException: Test Exception at org.apache.logging.log4j.LoggerTest.throwing(LoggerTest.java:596) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727) at org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131) at org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147) at org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93) at org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45) at org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92) at org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141) at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137) at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139) at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138) at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95) at org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185) at java.util.concurrent.RecursiveAction.exec(RecursiveAction.java:189) at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289) at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056) at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692) at
Re: Broken build
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
Re: Broken build
Edit: Because of the way these shared *listeners* are found... On Sun, May 4, 2014 at 9:38 AM, Bruce Brouwer bruce.brou...@gmail.comwrote: 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 -- Bruce Brouwer
Re: Broken build
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:
Re: Broken build
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
Re: Broken build
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
Re: Broken build
Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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:
Re: Broken build
This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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
Re: Broken build
No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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.
Re: Broken build
Oh phew. Well, I'll leave that to you if you wanted to continue what you were working on. All I added was a check on close() to compare against the current System.out and System.err. I'll take a look into OpenJDK to see how to properly lock those (if possible) to prevent fun race conditions. On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote: No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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
Re: Broken build
Looks like there's nothing to synchronise on actually. Guess you can just cache them before the check in general. On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote: Oh phew. Well, I'll leave that to you if you wanted to continue what you were working on. All I added was a check on close() to compare against the current System.out and System.err. I'll take a look into OpenJDK to see how to properly lock those (if possible) to prevent fun race conditions. On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote: No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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.comwrote: 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
Re: Broken build
I haven't spent much time on this since my initial attempt on 609. Shall I leave it to Ralph to come up with the final solution, or would you like me to try? On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote: Looks like there's nothing to synchronise on actually. Guess you can just cache them before the check in general. On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote: Oh phew. Well, I'll leave that to you if you wanted to continue what you were working on. All I added was a check on close() to compare against the current System.out and System.err. I'll take a look into OpenJDK to see how to properly lock those (if possible) to prevent fun race conditions. On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote: No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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.comwrote: I just fixed it in r1592291 haha On 3 May 2014 17:54, Ralph Goers ralph.go...@dslextreme.comwrote: 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.comwrote: 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
Re: Broken build
I was hoping to hear from Ralph as it sounds like he already started something. On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote: If you've got a good idea on how to do it, sure. On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote: I haven't spent much time on this since my initial attempt on 609. Shall I leave it to Ralph to come up with the final solution, or would you like me to try? On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote: Looks like there's nothing to synchronise on actually. Guess you can just cache them before the check in general. On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote: Oh phew. Well, I'll leave that to you if you wanted to continue what you were working on. All I added was a check on close() to compare against the current System.out and System.err. I'll take a look into OpenJDK to see how to properly lock those (if possible) to prevent fun race conditions. On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote: No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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.comwrote: 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.comwrote: I just fixed it in r1592291 haha On 3 May 2014 17:54, Ralph Goers ralph.go...@dslextreme.comwrote: 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.comwrote: 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.comwrote: Thanks, commenting out that test to verify my changes was exactly what I was doing now... :-)
Re: Broken build
Could you summarize how you'd implement this? Idea sharing could help reduce the overall effort required to elegantly fix this. On 4 May 2014 16:00, Bruce Brouwer bruce.brou...@gmail.com wrote: I was hoping to hear from Ralph as it sounds like he already started something. On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote: If you've got a good idea on how to do it, sure. On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote: I haven't spent much time on this since my initial attempt on 609. Shall I leave it to Ralph to come up with the final solution, or would you like me to try? On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote: Looks like there's nothing to synchronise on actually. Guess you can just cache them before the check in general. On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote: Oh phew. Well, I'll leave that to you if you wanted to continue what you were working on. All I added was a check on close() to compare against the current System.out and System.err. I'll take a look into OpenJDK to see how to properly lock those (if possible) to prevent fun race conditions. On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote: No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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.comwrote: 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.comwrote: I just fixed it in r1592291 haha On 3 May 2014 17:54, Ralph Goers ralph.go...@dslextreme.comwrote: 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.comwrote: 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
Re: Broken build
I plan on removing the “extends Closeable” from the StatusListener interface and then creating a StatusCloseableListener that extends StatusConsoleListener. The close method will move there. Then in StatusConfiguration we will create the appropriate type based on what the destination is set to. I may choose to create a static map in StatusCloseableListener and keep a counter for each destination name or I may just use the property that says whether it is a web container and not close the files if it is. I am not sure yet which would be the best option. Ralph On May 4, 2014, at 4:30 PM, Matt Sicker boa...@gmail.com wrote: Could you summarize how you'd implement this? Idea sharing could help reduce the overall effort required to elegantly fix this. On 4 May 2014 16:00, Bruce Brouwer bruce.brou...@gmail.com wrote: I was hoping to hear from Ralph as it sounds like he already started something. On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote: If you've got a good idea on how to do it, sure. On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote: I haven't spent much time on this since my initial attempt on 609. Shall I leave it to Ralph to come up with the final solution, or would you like me to try? On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote: Looks like there's nothing to synchronise on actually. Guess you can just cache them before the check in general. On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote: Oh phew. Well, I'll leave that to you if you wanted to continue what you were working on. All I added was a check on close() to compare against the current System.out and System.err. I'll take a look into OpenJDK to see how to properly lock those (if possible) to prevent fun race conditions. On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote: No, it can be simpler than that. Sent from my iPad On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote: This is starting to sound like we need a full-blown factory/context/logger implementation of StatusLogger. On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote: Also, that doesn't solve the case Remko mentioned of multiple web apps writing to a single file. 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
Re: Broken build
I was thinking of something along these lines (since Matt was asking me for
my ideas):
First off, make StatusConsoleListener a base class for
StatusSystemOutListener and StatusSystemErrListener (maybe inner classes).
These would no longer need to hold a reference to System.out or System.err,
so they will implictly follow any changes to System.out or System.err.
Then make a new StatusFileListener for handling files and this class would
know to close output streams. This class could hold a static map of
listeners. We could either do reference counting here or my preference -
register the Configuration with StatusFileListener to get the listener. e.g.
static StatusFileListener register(Configuration config, String fileName) {
... }
static void StatusFileListener release(Configuration config) { ... }
In the XMLConfiguration (and JSONConfiguration) stop and reconfigure
methods, it would deal with releasing the config. This is hidden behind
StatusConfiguration, so it might involve XMLConfiguration and
JSONConfiguration maintaining a reference to StatusConfiguration. I haven't
totally decided yet what would be best.
(I was in the middle of typing this when I got Ralph's response)
On Sun, May 4, 2014 at 9:03 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
I plan on removing the “extends Closeable” from the StatusListener
interface and then creating a StatusCloseableListener that extends
StatusConsoleListener. The close method will move there. Then in
StatusConfiguration we will create the appropriate type based on what the
destination is set to. I may choose to create a static map in
StatusCloseableListener and keep a counter for each destination name or I
may just use the property that says whether it is a web container and not
close the files if it is. I am not sure yet which would be the best option.
Ralph
On May 4, 2014, at 4:30 PM, Matt Sicker boa...@gmail.com wrote:
Could you summarize how you'd implement this? Idea sharing could help
reduce the overall effort required to elegantly fix this.
On 4 May 2014 16:00, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was hoping to hear from Ralph as it sounds like he already started
something.
On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote:
If you've got a good idea on how to do it, sure.
On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote:
I haven't spent much time on this since my initial attempt on 609.
Shall I leave it to Ralph to come up with the final solution, or would you
like me to try?
On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote:
Looks like there's nothing to synchronise on actually. Guess you can
just cache them before the check in general.
On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote:
Oh phew. Well, I'll leave that to you if you wanted to continue what
you were working on. All I added was a check on close() to compare
against
the current System.out and System.err. I'll take a look into OpenJDK to
see
how to properly lock those (if possible) to prevent fun race conditions.
On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote:
No, it can be simpler than that.
Sent from my iPad
On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote:
This is starting to sound like we need a full-blown
factory/context/logger implementation of StatusLogger.
On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote:
Also, that doesn't solve the case Remko mentioned of multiple web
apps writing to a single file.
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
Re: Broken build
It sounds like we are on a similar approach.
Even with registering the Configuration with the StatusFileListener it is
possible that multiple configurations would want to write to the same file, and
so should share the same Listener. In that case closing the file would only
happen when the last Configuration is unregistered.
Ralph
On May 4, 2014, at 6:06 PM, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was thinking of something along these lines (since Matt was asking me for
my ideas):
First off, make StatusConsoleListener a base class for
StatusSystemOutListener and StatusSystemErrListener (maybe inner classes).
These would no longer need to hold a reference to System.out or System.err,
so they will implictly follow any changes to System.out or System.err.
Then make a new StatusFileListener for handling files and this class would
know to close output streams. This class could hold a static map of
listeners. We could either do reference counting here or my preference -
register the Configuration with StatusFileListener to get the listener. e.g.
static StatusFileListener register(Configuration config, String fileName) {
... }
static void StatusFileListener release(Configuration config) { ... }
In the XMLConfiguration (and JSONConfiguration) stop and reconfigure methods,
it would deal with releasing the config. This is hidden behind
StatusConfiguration, so it might involve XMLConfiguration and
JSONConfiguration maintaining a reference to StatusConfiguration. I haven't
totally decided yet what would be best.
(I was in the middle of typing this when I got Ralph's response)
On Sun, May 4, 2014 at 9:03 PM, Ralph Goers ralph.go...@dslextreme.com
wrote:
I plan on removing the “extends Closeable” from the StatusListener interface
and then creating a StatusCloseableListener that extends
StatusConsoleListener. The close method will move there. Then in
StatusConfiguration we will create the appropriate type based on what the
destination is set to. I may choose to create a static map in
StatusCloseableListener and keep a counter for each destination name or I may
just use the property that says whether it is a web container and not close
the files if it is. I am not sure yet which would be the best option.
Ralph
On May 4, 2014, at 4:30 PM, Matt Sicker boa...@gmail.com wrote:
Could you summarize how you'd implement this? Idea sharing could help reduce
the overall effort required to elegantly fix this.
On 4 May 2014 16:00, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was hoping to hear from Ralph as it sounds like he already started
something.
On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote:
If you've got a good idea on how to do it, sure.
On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote:
I haven't spent much time on this since my initial attempt on 609. Shall I
leave it to Ralph to come up with the final solution, or would you like me
to try?
On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote:
Looks like there's nothing to synchronise on actually. Guess you can just
cache them before the check in general.
On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote:
Oh phew. Well, I'll leave that to you if you wanted to continue what you
were working on. All I added was a check on close() to compare against the
current System.out and System.err. I'll take a look into OpenJDK to see how
to properly lock those (if possible) to prevent fun race conditions.
On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote:
No, it can be simpler than that.
Sent from my iPad
On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote:
This is starting to sound like we need a full-blown factory/context/logger
implementation of StatusLogger.
On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote:
Also, that doesn't solve the case Remko mentioned of multiple web apps
writing to a single file.
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
Re: Broken build
So, who gets to implement it. Ralph, is your time better spent on other
log4j issues, or should I look for new opportunities to help here? Any
suggestions?
On Sun, May 4, 2014 at 9:25 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
It sounds like we are on a similar approach.
Even with registering the Configuration with the StatusFileListener it is
possible that multiple configurations would want to write to the same file,
and so should share the same Listener. In that case closing the file would
only happen when the last Configuration is unregistered.
Ralph
On May 4, 2014, at 6:06 PM, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was thinking of something along these lines (since Matt was asking me
for my ideas):
First off, make StatusConsoleListener a base class for
StatusSystemOutListener and StatusSystemErrListener (maybe inner classes).
These would no longer need to hold a reference to System.out or System.err,
so they will implictly follow any changes to System.out or System.err.
Then make a new StatusFileListener for handling files and this class would
know to close output streams. This class could hold a static map of
listeners. We could either do reference counting here or my preference -
register the Configuration with StatusFileListener to get the listener. e.g.
static StatusFileListener register(Configuration config, String fileName)
{ ... }
static void StatusFileListener release(Configuration config) { ... }
In the XMLConfiguration (and JSONConfiguration) stop and reconfigure
methods, it would deal with releasing the config. This is hidden behind
StatusConfiguration, so it might involve XMLConfiguration and
JSONConfiguration maintaining a reference to StatusConfiguration. I haven't
totally decided yet what would be best.
(I was in the middle of typing this when I got Ralph's response)
On Sun, May 4, 2014 at 9:03 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
I plan on removing the “extends Closeable” from the StatusListener
interface and then creating a StatusCloseableListener that extends
StatusConsoleListener. The close method will move there. Then in
StatusConfiguration we will create the appropriate type based on what the
destination is set to. I may choose to create a static map in
StatusCloseableListener and keep a counter for each destination name or I
may just use the property that says whether it is a web container and not
close the files if it is. I am not sure yet which would be the best option.
Ralph
On May 4, 2014, at 4:30 PM, Matt Sicker boa...@gmail.com wrote:
Could you summarize how you'd implement this? Idea sharing could help
reduce the overall effort required to elegantly fix this.
On 4 May 2014 16:00, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was hoping to hear from Ralph as it sounds like he already started
something.
On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote:
If you've got a good idea on how to do it, sure.
On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote:
I haven't spent much time on this since my initial attempt on 609.
Shall I leave it to Ralph to come up with the final solution, or would you
like me to try?
On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote:
Looks like there's nothing to synchronise on actually. Guess you can
just cache them before the check in general.
On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote:
Oh phew. Well, I'll leave that to you if you wanted to continue what
you were working on. All I added was a check on close() to compare
against
the current System.out and System.err. I'll take a look into OpenJDK to
see
how to properly lock those (if possible) to prevent fun race conditions.
On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote:
No, it can be simpler than that.
Sent from my iPad
On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote:
This is starting to sound like we need a full-blown
factory/context/logger implementation of StatusLogger.
On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote:
Also, that doesn't solve the case Remko mentioned of multiple web
apps writing to a single file.
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
Re: Broken build
Go for it!
Ralph
On May 4, 2014, at 7:04 PM, Bruce Brouwer bruce.brou...@gmail.com wrote:
So, who gets to implement it. Ralph, is your time better spent on other log4j
issues, or should I look for new opportunities to help here? Any suggestions?
On Sun, May 4, 2014 at 9:25 PM, Ralph Goers ralph.go...@dslextreme.com
wrote:
It sounds like we are on a similar approach.
Even with registering the Configuration with the StatusFileListener it is
possible that multiple configurations would want to write to the same file,
and so should share the same Listener. In that case closing the file would
only happen when the last Configuration is unregistered.
Ralph
On May 4, 2014, at 6:06 PM, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was thinking of something along these lines (since Matt was asking me for
my ideas):
First off, make StatusConsoleListener a base class for
StatusSystemOutListener and StatusSystemErrListener (maybe inner classes).
These would no longer need to hold a reference to System.out or System.err,
so they will implictly follow any changes to System.out or System.err.
Then make a new StatusFileListener for handling files and this class would
know to close output streams. This class could hold a static map of
listeners. We could either do reference counting here or my preference -
register the Configuration with StatusFileListener to get the listener. e.g.
static StatusFileListener register(Configuration config, String fileName) {
... }
static void StatusFileListener release(Configuration config) { ... }
In the XMLConfiguration (and JSONConfiguration) stop and reconfigure
methods, it would deal with releasing the config. This is hidden behind
StatusConfiguration, so it might involve XMLConfiguration and
JSONConfiguration maintaining a reference to StatusConfiguration. I haven't
totally decided yet what would be best.
(I was in the middle of typing this when I got Ralph's response)
On Sun, May 4, 2014 at 9:03 PM, Ralph Goers ralph.go...@dslextreme.com
wrote:
I plan on removing the “extends Closeable” from the StatusListener
interface and then creating a StatusCloseableListener that extends
StatusConsoleListener. The close method will move there. Then in
StatusConfiguration we will create the appropriate type based on what the
destination is set to. I may choose to create a static map in
StatusCloseableListener and keep a counter for each destination name or I
may just use the property that says whether it is a web container and not
close the files if it is. I am not sure yet which would be the best
option.
Ralph
On May 4, 2014, at 4:30 PM, Matt Sicker boa...@gmail.com wrote:
Could you summarize how you'd implement this? Idea sharing could help
reduce the overall effort required to elegantly fix this.
On 4 May 2014 16:00, Bruce Brouwer bruce.brou...@gmail.com wrote:
I was hoping to hear from Ralph as it sounds like he already started
something.
On May 4, 2014 3:22 PM, Matt Sicker boa...@gmail.com wrote:
If you've got a good idea on how to do it, sure.
On 4 May 2014 14:04, Bruce Brouwer bruce.brou...@gmail.com wrote:
I haven't spent much time on this since my initial attempt on 609.
Shall I leave it to Ralph to come up with the final solution, or would
you like me to try?
On May 4, 2014 2:35 PM, Matt Sicker boa...@gmail.com wrote:
Looks like there's nothing to synchronise on actually. Guess you can
just cache them before the check in general.
On 4 May 2014 13:25, Matt Sicker boa...@gmail.com wrote:
Oh phew. Well, I'll leave that to you if you wanted to continue what
you were working on. All I added was a check on close() to compare
against the current System.out and System.err. I'll take a look into
OpenJDK to see how to properly lock those (if possible) to prevent
fun race conditions.
On 4 May 2014 13:11, Ralph Goers rgo...@apache.org wrote:
No, it can be simpler than that.
Sent from my iPad
On May 4, 2014, at 10:55 AM, Matt Sicker boa...@gmail.com wrote:
This is starting to sound like we need a full-blown
factory/context/logger implementation of StatusLogger.
On 4 May 2014 12:46, Ralph Goers rgo...@apache.org wrote:
Also, that doesn't solve the case Remko mentioned of multiple web
apps writing to a single file.
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.
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(new InitialLoggerContext(CONFIG)); How do I fix this? Remko
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 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
Re: Broken build
Yes, windows 7. On Sun, May 4, 2014 at 12:54 AM, Ralph Goers ralph.go...@dslextreme.comwrote: 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
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 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
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 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
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 ralph.go...@dslextreme.comwrote: 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.comwrote: 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
Re: Broken build
Better: add @Ignore next to @Test. Gary div Original message /divdivFrom: Remko Popma remko.po...@gmail.com /divdivDate:05/03/2014 12:22 (GMT-05:00) /divdivTo: Log4J Developers List log4j-dev@logging.apache.org /divdivSubject: Re: Broken build /divdiv /divThanks, 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
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, 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.comwrote: 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.comwrote: 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
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 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.comwrote: 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
Re: Broken build
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
Re: Broken build
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
Re: Broken build
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.comwrote: 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
Re: Broken build
Never mind. I am fixing it. Ralph On May 3, 2014, at 3:10 PM, 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
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 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
Re: Broken build
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
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 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
Re: Broken build
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
