- Refactor the setup of class loaders so that it is clearer what is
going on
- For the Log4J tests, add the custom Appender implementation to
whichever class loader Log4J is put in
- Set and reset the thread context class loader to more accurately
simulate the environment of a servlet container.
build.xml:
- Implement the multi-classloader test scenarios for Log4J, equivalent
to those for JDK 1.4.
We now have a robust testing environment to catch any possible regressions
when modifying the functionality (such as ripping out Log4jFactory, as
discussed on COMMONS-DEV).
I don't have time to do the corresponding test scenarios for Avalon LogKit,
but anyone who wants to do so is welcome to create them.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138965 13f79535-47bb-0310-9956-ffa450edef68
one exactly like the default configuration of Tomcat 4.1 (with c-l placed
inside the webapp) and one where you put c-l in the parent class loader
(in place of commons-logging-api.jar) so webapps do not have to.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138959 13f79535-47bb-0310-9956-ffa450edef68
the tests run when everything is in the system class loader -- need to add
execution wrappers for two-tier class loaders where:
* commons-logging.jar is in the parent and test execution is in the child
* commons-logging-api.jar is in the parent and test execution plus
commons-logging.jar is in the child
to simulate container environments like that you get running inside Tomcat.
Later on, we'll want an analogous set of tests for Log4J.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138958 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
( we should probably add the other loggers - only what is found is used,
it doesn't hurt anyone ).
Even if most containers will automatically add whatever is in lib, if you
use it in command line things are more difficult.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138885 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
