- 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
The way I use it is:
<ant dir="${cvs.base}/jakarta-commons/logging" target="compile-only" >
<property name="commons-logging-api.jar" location="${build.dir}/lib/commons-logging-api.jar" />
<property name="commons-logging.jar" location="${build.dir}/lib/commons-logging.jar" />
<property name="build.home" value="${build.dir}" />
</ant>
If it brakes something or any other problem - please let me know.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138929 13f79535-47bb-0310-9956-ffa450edef68
logger and the adapters to sit in the WEB-INF ( and multiple loggers to be used ),
while having commons-logging in the root classloader.
( this in turns allow various components that are loaded with the root loader
to log ).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138887 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
Default behavior of LogSource.getInstance() is now:
* If Log4J is available, return an instance of Log4JCategoryLog
* If JDK 1.4 is available, return an instance of Jdk14Logger
* Otherwise, return an instance of NoOpLogger
As before, this default behavior can be overridden with a system
property, or by calling LogSource.setLogImplementation(), as described
in the package Javadocs.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138829 13f79535-47bb-0310-9956-ffa450edef68
