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:
>
>
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
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
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
>
>
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
>>
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
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]
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
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
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.
>
>
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]
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,
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
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
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
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
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
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
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:
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
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
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
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
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
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 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
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
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
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
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
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
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?
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
46 matches
Mail list logo
