I don't think adding things to core at this point adds an expectation on
log4j 2.0 at all personally. I'm against creating a logging attic.
Receivers are the other half of appenders. Unless you only care about
fileappenders, they have utility.
I'd still prefer to see things moved in to core. Ou
I used Nexus for the last release of log4j and struggled with it. If I remember
correctly there were issues with our Maven group ID not starting with
org.apache that prevented the release from being mirrored to Maven central, but
think we finally worked through all the issues.
I would not be in
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
--- Comment #2 from David North 2011-10-06
16:29:35 UTC ---
To expand a little on comment 1 ... the solution proposed in comment 0 would
work, but it seems more risky to victimize a random log.debug/info call to do
the work of checking if
https://issues.apache.org/bugzilla/show_bug.cgi?id=49571
--- Comment #1 from David North 2011-10-06
16:26:08 UTC ---
I've implemented a workaround in my J2EE app which involves subclassing
FileWatchdog and adding a shutdown() method to interrupt its thread at
application undeploy/shutdown.
Sinc
https://issues.apache.org/bugzilla/show_bug.cgi?id=51979
Bug #: 51979
Summary: Fix for bug 42087 introduces line truncating in syslog
for lines longer than 1024 bytes
Product: Log4j
Version: 1.2
Platform: PC
OS/Ver
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project logging-log4j-receivers has an issue affecting its community
integration.
