I approve the message and that is permanent apache.org has any time in need
i got u. And I need a job lol
On Mon, Apr 19, 2021, 4:41 PM Tim Perry wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener
I finally with the great help from you and apache.org friends ❤ thanks
they killed my credibility
On Mon, Apr 19, 2021, 4:41 PM Tim Perry wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
>
You will let treyha...@gmail.com join again and thank you
On Mon, Apr 19, 2021, 4:41 PM Tim Perry wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
> registering the context name there.
>
> In
No it’s fine you can stay.
“Ban me i can't get him off she'll” is just pure poetry. More please. :-)
> On Apr 20, 2021, at 10:03, Sixx XT wrote:
>
> Ban me i can't get him off she'll
Ban me i can't get him off she'll
On Mon, Apr 19, 2021, 9:01 PM Remko Popma wrote:
> Sixx XT appears to be a robot.
> Ban?
>
> Sixx XT, you can redeem yourself with an intelligent response to this
> message.
>
> On Tue, Apr 20, 2021 at 6:04 Sixx XT wrote:
>
> > They figured it out through the
Sixx XT appears to be a robot.
Ban?
Sixx XT, you can redeem yourself with an intelligent response to this
message.
On Tue, Apr 20, 2021 at 6:04 Sixx XT wrote:
> They figured it out through the drive the guy that was hacking me and stole
> my dev in 2016 Oct is under apache 2.2
>
> On
They figured it out through the drive the guy that was hacking me and stole
my dev in 2016 Oct is under apache 2.2
On Mon, Apr 19, 2021, 4:53 PM Sixx XT wrote:
> Look out for dup() files
>
> On Mon, Apr 19, 2021, 4:52 PM Sixx XT wrote:
>
>> Thank you im sorry when I find a job ill pay u
Look out for dup() files
On Mon, Apr 19, 2021, 4:52 PM Sixx XT wrote:
> Thank you im sorry when I find a job ill pay u
>
> On Mon, Apr 19, 2021, 4:48 PM Sixx XT wrote:
>
>> Do I need to disable drive
>>
>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry wrote:
>>
>>> After further thought, I am
Thank you im sorry when I find a job ill pay u
On Mon, Apr 19, 2021, 4:48 PM Sixx XT wrote:
> Do I need to disable drive
>
> On Mon, Apr 19, 2021, 4:41 PM Tim Perry wrote:
>
>> After further thought, I am threading the context name into the location
>> where the StatusConfiguration creates the
Do I need to disable drive
On Mon, Apr 19, 2021, 4:41 PM Tim Perry wrote:
> After further thought, I am threading the context name into the location
> where the StatusConfiguration creates the StatusConsoleListener and
> registering the context name there.
>
> In addition, if the new logger
After further thought, I am threading the context name into the location
where the StatusConfiguration creates the StatusConsoleListener and
registering the context name there.
In addition, if the new logger would write to a destination other than
standard out or standard error then I do not
Tha rsa-sha256 could be i wrote the event off fake web page should I delete
my events
On Mon, Apr 19, 2021, 3:17 PM Tim Perry wrote:
> I rewrote this to shut down listeners based on the contextName. In testing,
> I discovered that the StatusConsoleListener is created in
> StatusConfiguration,
I rewrote this to shut down listeners based on the contextName. In testing,
I discovered that the StatusConsoleListener is created in
StatusConfiguration, but neither StatusConfiguration nor
StatusConsoleListener receive events to indicate when they should stop.
It appears that only one
The StatusLogger has various listeners attached. I think adding and
removing listeners on startup and shutdown of a LoggerContext might be
a potential way to do this?
On Wed, 24 Feb 2021 at 01:07, Tim Perry wrote:
>
> Ralph,
>
> Thanks for the review. Yep, that *is* a problem...I knew it was a
Ralph,
Thanks for the review. Yep, that *is* a problem...I knew it was a singleton
but didn't think through the use case you describe. This is ironic since a
few months ago I recommended that one of my clients bundle log4j in each
war rather than on Tomcat's classpath so there would be less
Yeah, I started a review but then I thought it probably would be better to
respond here.
You are on the right track but there is a problem. StatusLogger is a singleton
- there is one instance anchored in a static. You are invoking the shutdown
logic from the shutdown of the LoggerContext which
Ralph,
I implemented what you suggested. Feel free to suggest improvements.
https://github.com/apache/logging-log4j2/pull/469
Tim
On Tue, Feb 23, 2021 at 2:14 PM Ralph Goers
wrote:
> I would suggest that if it is writing to something other than System.out
> that it be redirected back there
I would suggest that if it is writing to something other than System.out that
it be redirected back there and then the OutputStream be closed. However, I’ve
not looked at the code recently so I am not sure what it takes to do that.
Ralph
> On Feb 23, 2021, at 2:22 PM, Tim Perry wrote:
>
>
Thank you for the feedback. I'll put in a pull request.
On Tue, Feb 23, 2021 at 1:29 PM Volkan Yazıcı
wrote:
> I still would favor a PR – it greatly narrows down the scope one needs to
> wrap his/her head around. Not to mention the convenience of having the
> discussion "on the code".
>
> Ralph
I still would favor a PR – it greatly narrows down the scope one needs to
wrap his/her head around. Not to mention the convenience of having the
discussion "on the code".
Ralph appears to be the best candidate to answer your questions. But again,
a PR would incentivize others to chime in too.
Thank you, Volkan.
I'm not quite ready to submit a PR. I was hoping some of you with more
knowledge of log4j-core would weigh in on what we should do about shutting
down the StatusLogger.
My thought is we choose one of two options:
Option A:
1) check if any StatusLogger is writing to standard
Great work Tim! I can't be happier finally somebody stepping up to fix
sporadic build failures on Windows due to open file related issues. Would
you mind creating a PR, please? (I haven't missed one, right?) This will
make it easier to review your changes and merge them.
On Mon, Feb 22, 2021 at
I have a fork of log4j2 master that builds on windows here:
https://github.com/perry2of5/logging-log4j2
For log4j-core, I close the StatusLogger using
StatusLogger.getLogger().reset() to LoggerContext.stop(...). Now
log4j2-core tests pass. (Usually). I doubt this is the best solution, but
it
The simplest fix is to add "StatusLogger.getLogger().reset();" to the very
end of LoggerContext.stop(timeout, timeUnit).
However, I'm not sure that is a great idea -- all status messages after
that point would be lost.
Perhaps we want to have some logic that updates the LoggerContext to have
one
This is a very good observation. When the status logger was implemented it
targeted System.out, which you obviously never want to close. Shortly there
after the ability to route it to a file instead was added. I guess we just
never thought to add logic to close it at shutdown.
Ralph
> On Feb
> My guess is that the default file locking level is different
> between JVM's or OS's.
My understanding with Windows is that when you open a file, you have
exclusive access by default. If you try to delete a file that another
application has open(or possibly even your application?), you'll get
It looks to me like LoggerContext.stop(...) closes the file 'test.log'.
However, I can't find anything closing 'status.log'. They are configured in
the same XML file: log4j-filetest.xml
target/test.log
...
I modified the @Test from
The gist of what I recall the problem being was that sometimes, a file
might still be in use asynchronously for various appenders (e.g.,
during rolling, compression, etc.), so the shutdown and removal of
temporary files needs to signal that the configuration needs to shut
down. It looks like you
Yes, I am on windows 10. I'm using Zulu OpenJdk for both Java 8 and 11,
maven 3.6.3, and a fairly new Eclipse. I'd be happy to help you sort out
the problem. It will be fun: I haven't played around with those junit
features.
On Wed, Feb 17, 2021 at 1:45 PM Matt Sicker wrote:
> Is that on
Is that on Windows? If so, there seems to be a bug I've introduced in
the JUnit 5 code that I tried to port from the JUnit 4 code correctly,
but I don't have a Windows machine to test that out on iteratively.
See
I mean is that:
* when I run "mvn install" on the command line then usually 1, but
sometimes 2 tests fail.
* when I right-click the src/tests/java folder in eclipse and do "run as
JUnit" I get ~100 failures.
I'm fairly sure the tests are *not* running in parallel.
On Wed, Feb 17, 2021 at 1:11
I think he's referring to the need to run mvn install once before the
IDE will pick up snapshot jars for things like annotation processing
or other fancy things. Simple way to reproduce: try running "mvn
package" without the "install" target.
On Wed, 17 Feb 2021 at 13:58, Ralph Goers wrote:
>
>
Yeah, there is a very good chance if you are trying to run tests in core in
parallel on multiple threads that they will fail. Most of them expect their own
LoggerContext.
Ralph
> On Feb 17, 2021, at 12:51 PM, Tim Perry wrote:
>
> On master, I noticed that when I build in my IDE that lots of
On master, I noticed that when I build in my IDE that lots of tests in
log4j-core fail but when I build with maven they pass. In the past, when
I've seen this on other projects it was caused by race conditions. I
wonder: are there race conditions in the tests or the code that need to be
addressed?
Yes, that is why I am wondering why master is so flaky.
Ralph
> On Feb 7, 2021, at 2:34 PM, Gary Gregory wrote:
>
> FWIW but not master, I've been building release-2.x lately over and over
> without issues aside from the rare random failure.
>
> G
>
> On Sun, Feb 7, 2021 at 2:37 PM Matt
FWIW but not master, I've been building release-2.x lately over and over
without issues aside from the rare random failure.
G
On Sun, Feb 7, 2021 at 2:37 PM Matt Sicker wrote:
> I'm not getting errors in log4j-api, though it's possible some test is
> missing a JUnit annotation which is causing
I'm not getting errors in log4j-api, though it's possible some test is
missing a JUnit annotation which is causing that ThreadContext data
corruption.
I am, however, getting the same log4j-kafka test error. I'll try
running the log4j-api tests a few more times to see if I can reproduce
any test
37 matches
Mail list logo
