- 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
