Go for it!
Ralph
> On May 4, 2014, at 7:04 PM, Bruce Brouwer 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
>> 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 wrote:
> It sounds like we are on a similar approach.
>
> Even with registering the Configuratio
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 la
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 th
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.
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 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"
I was hoping to hear from Ralph as it sounds like he already started
something.
On May 4, 2014 3:22 PM, "Matt Sicker" wrote:
> If you've got a good idea on how to do it, sure.
>
>
> On 4 May 2014 14:04, Bruce Brouwer wrote:
>
>> I haven't spent much time on this since my initial attempt on 609.
If you've got a good idea on how to do it, sure.
On 4 May 2014 14:04, Bruce Brouwer 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"
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" wrote:
> Looks like there's nothing to synchronise on actually. Guess you can just
> cache them befor
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 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 a
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
No, it can be simpler than that.
Sent from my iPad
> On May 4, 2014, at 10:55 AM, Matt Sicker 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 wrote:
>> Also, that doesn't solve th
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 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
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 wrote:
>
> So how about adding a check at construction checking against System.out and
> System.err? Really, once you start messing with those strea
That is what I was doing yesterday before I got your "haha" email.
Ralph
> On May 4, 2014, at 9:53 AM, Matt Sicker 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'l
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 wrote:
> I see two choices here - ma
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 wor
Edit: Because of the way these shared *listeners* are found...
On Sun, May 4, 2014 at 9:38 AM, Bruce Brouwer 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
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
Hooray, we've finally figured out the bug. :)
On 3 May 2014 19:49, Remko Popma wrote:
> I just updated from SVN and all tests now pass.
> The build works now. Thanks!
>
>
> On Sun, May 4, 2014 at 7:55 AM, Matt Sicker wrote:
>
>> I just fixed it in r1592291 haha
>>
>>
>> On 3 May 2014 17:54, Ra
I just updated from SVN and all tests now pass.
The build works now. Thanks!
On Sun, May 4, 2014 at 7:55 AM, Matt Sicker wrote:
> I just fixed it in r1592291 haha
>
>
> On 3 May 2014 17:54, Ralph Goers wrote:
>
>> Yes. It cause them to close. Anything written to System.out or System.err
>> wil
I just fixed it in r1592291 haha
On 3 May 2014 17:54, Ralph Goers wrote:
> Yes. It cause them to close. Anything written to System.out or System.err
> will fail.
>
> On May 3, 2014, at 3:51 PM, Matt Sicker wrote:
>
> Does closing them do anything?
>
>
> On 3 May 2014 17:10, Ralph Goers wrote:
Yes. It cause them to close. Anything written to System.out or System.err will
fail.
On May 3, 2014, at 3:51 PM, Matt Sicker wrote:
> Does closing them do anything?
>
>
> On 3 May 2014 17:10, Ralph Goers wrote:
> Perhaps we need a StatusFileListerner when writing to a file?
>
> Ralph
>
> O
Never mind. I am fixing it.
Ralph
On May 3, 2014, at 3:10 PM, Ralph Goers wrote:
> Perhaps we need a StatusFileListerner when writing to a file?
>
> Ralph
>
> On May 3, 2014, at 3:03 PM, Ralph Goers wrote:
>
>> System.out or System.err should never be closed.
>>
>> Ralph
>>
>> On May 3, 2
Does closing them do anything?
On 3 May 2014 17:10, Ralph Goers wrote:
> Perhaps we need a StatusFileListerner when writing to a file?
>
> Ralph
>
> On May 3, 2014, at 3:03 PM, Ralph Goers
> wrote:
>
> System.out or System.err should never be closed.
>
> Ralph
>
> On May 3, 2014, at 10:59 AM,
Perhaps we need a StatusFileListerner when writing to a file?
Ralph
On May 3, 2014, at 3:03 PM, Ralph Goers wrote:
> System.out or System.err should never be closed.
>
> Ralph
>
> On May 3, 2014, at 10:59 AM, Matt Sicker wrote:
>
>> I've implemented Closeable on StatusListener in r1592258.
System.out or System.err should never be closed.
Ralph
On May 3, 2014, at 10:59 AM, Matt Sicker wrote:
> I've implemented Closeable on StatusListener in r1592258. Please try out the
> unit tests again and let me know if this solves the issue on Windows.
>
>
> On 3 May 2014 12:30, Matt Sicker
I've implemented Closeable on StatusListener in r1592258. Please try out
the unit tests again and let me know if this solves the issue on Windows.
On 3 May 2014 12:30, Matt Sicker wrote:
> I think this is actually a bug. StatusListener should implement Closeable,
> and when the listeners are cl
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
Better: add @Ignore next to @Test.
Gary
Original message From: Remko Popma
Date:05/03/2014 12:22 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Broken build
Thanks, commenting out that test to verify my changes was exactly what I
was doing now... :-)
On Sun, May
Thanks, commenting out that test to verify my changes was exactly what I
was doing now... :-)
On Sun, May 4, 2014 at 1:20 AM, Ralph Goers wrote:
>
> Oh, and if you are trying to do some work just comment out the @Test of
> the failing test - but don’t commit that.
>
> Ralph
>
>
>
> On May 3, 20
Oh, and if you are trying to do some work just comment out the @Test of the
failing test - but don’t commit that.
Ralph
On May 3, 2014, at 9:19 AM, Ralph Goers wrote:
> That happens because the file is still being referenced by something when it
> is trying to delete it. It should be becau
That happens because the file is still being referenced by something when it is
trying to delete it. It should be because the file is open but I recall
reading that Windows sometimes holds on to file references longer than it
should. This was probably caused by the changes Matt made to the uni
Yes, windows 7.
On Sun, May 4, 2014 at 12:54 AM, Ralph Goers wrote:
> FileOutputTest was failing for me last week and I thought I fixed it. But
> it was failing because the file was empty, not because it couldn’t be
> deleted. I guess you must be running on Windows?
>
> Ralph
>
> On May 3, 2014,
FileOutputTest was failing for me last week and I thought I fixed it. But it
was failing because the file was empty, not because it couldn’t be deleted. I
guess you must be running on Windows?
Ralph
On May 3, 2014, at 8:44 AM, Remko Popma wrote:
> When I run mvn clean install, I get this prob
35 matches
Mail list logo
