the "proxy log factory" class o.a.c.l.impl.Log4jFactory (which didn't really
accomplish any functional purpose), and remove from LogFactoryImpl the
creation and use of a proxy instance.
PR: Bugzilla #17561
Submitted by: Felix Janssen <thundur at mayaxatl.org>
PR: Bugzilla #17894
Submitted by: Nathan Niesen <nathann at objectfx.com>
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138967 13f79535-47bb-0310-9956-ffa450edef68
* Out of scope for commons-logging, which promises only to wrap
USE of the logging implementation, not configuration.
* Incorrect assumption that not having appenders configured on the
root logger is an error.
* Log4J will auto-configure itself if a log4j.xml or log4j.properties
file is present, so out-of-the-box use with no code is as simple
as dropping a properties file in the correct place.
PR: Bugzilla #13201
Submitted by: Steven Caswell <stevencaswell at apache.org>
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138966 13f79535-47bb-0310-9956-ffa450edef68
"java.util.logging.Logger" to "java.sql.Savepoint". This means
that a JDK 1.3 JVM with an alternative JSR-47 (logging jsr) implementation
available will not be mis-identified as a JDK 1.4 system.
PR: Bugzilla #16606
Submitted by: Andreas Wendt <wen at eigner.com>
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138951 13f79535-47bb-0310-9956-ffa450edef68
and replace it with a new Log4JLogger implementation that wraps an
o.a.l.Logger instance instead.
Update docco to reflect that Log4J support is now for version 1.2 or later
(when o.a.l.Logger was introduced).
PR: 13118
Submitted by: Paul Campbell <seapwc at halycon.com>
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138940 13f79535-47bb-0310-9956-ffa450edef68
default appender.
I still have some problems with log4j's JMX if I construct the logger
via API ( i.e. no log4j.properties ) - but that shouldn't affect too
many people, so I'll leave it.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138888 13f79535-47bb-0310-9956-ffa450edef68
- if no log4j.properties is found, we'll construct a 'sane' config ( to be
consistent with the other loggers ). The appender must have a name ( otherwise
the JMX stuff in log4j will complain )
- fix the class name for the log4j factory
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138886 13f79535-47bb-0310-9956-ffa450edef68
- for JDK1.4, include the correct class/method. This uses a hack to
extract the information from the stack trace - probably slow, but
it's better to get the correct information.
- for log4j, check if log4j is initialized ( by checking if any appenders
are present ). Set a default configuration if it is not initialized.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138884 13f79535-47bb-0310-9956-ffa450edef68
even in environments (such as an Applet) where System.getProperty() throws
a security exception. Previously, this was causing the checks for Log4J or
JDK 1.4 logging to be skipped.
PR: Bugzilla #7468
Reported By: Tim Vernum (tpv at spamcop.net)
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138881 13f79535-47bb-0310-9956-ffa450edef68
> I've updated the Log4JCategoryLog.java to use the Log4J method Category.log
> () which allows the fully qualified class name (FQCN) of the user's logger
> class to be passed through into Log4J. In this case the logger class FQCN
> will be "org.apache.commons.logging.impl.Log4JCategoryLog". This allows
> Log4J to correctly identify the location in the code from which the logger
> is being called, if required. Without this Log4J reports that the calling
> location is ALWAYS Log4JCategoryLog.java:132.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138878 13f79535-47bb-0310-9956-ffa450edef68
that the commons-logging wrapper is also available before selecting it.
This avoids problems when using a copy of commons-logging.jar compiled on
a 1.3 system (and therefore missing the wrappe class) when executing on a
1.4 system.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138875 13f79535-47bb-0310-9956-ffa450edef68
a loader, and the thread loader is set to point to a different
loader that doesn't include logging ( or to a wrong value ).
This happens when logging is used in certain container components,
where the thread loader will point to an app that may not
have/use logging.
XXX What's the right order ? From a 'feature' point of view,
it's better to try the thread loader first, so apps can
override the default. From a security point of view,
we should try the Class.forName() first, i.e. whatever
is loaded in the parent loader.
The current fix leaves the original order ( with thread loader
used if available ).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138874 13f79535-47bb-0310-9956-ffa450edef68
