Add more comprehensive unit tests for SimpleLog, including the ability
to serialize and deserialize instances.
This work will form the basis for making similar changes to the other
Log implementations (and their corresponding test cases).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138990 13f79535-47bb-0310-9956-ffa450edef68
- 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
