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
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
- 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
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
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
Jon plus some additional thought about using it in a multi-class-loader
environment (like Tomcat):
* Changed newFactory() to getFactory(), and implemented a cache of
previously created factory instances (one per class loader). This
avoids potentially expensive and redundant discovery operations.
* Added convenient static getLog() method so a typical application
component can initialize it's Log instance like this:
Log log = LogFactory.getLog("com.mycompany.mypackage.MyClass");
* Added variants of getInstance() and getLog() that take a Class
parameter instead of a String. LogSource had this convenience
feature, and there's no reason not to keep it.
* Added release() and releaseAll() methods to instruct the factory
instances to release any cached references to other LogFactory
or Log instances. This is important, for example, if you put
commons-logging.jar in Tomcat's shared "lib" directory, and then
use the application reload facility. The references maintained
here would otherwise prevent garbage collection of the old
webapp class loader once a reload takes place.
* Added a note on getInstance() that you can make no assumptions
about whether or not the actual Log instance you get back is
shared or not. The actual sharability is a feature of the
LogFactory implementation you are using, and what kind of a
class loader environment you ae installing.
* Deprecated LogSource, but left it there to ease transition of
existing code using it.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138858 13f79535-47bb-0310-9956-ffa450edef68
(LogFactoryImpl) that is based on the principles of the JAXP API's approach
to discovering SAXParserFactory and DocumentBuilderFactory instances. It
addresses the technical concerns that Costin brought up in response to the
original Commons Logging 1.0 vote.
The primary new features:
* Applications can select their own LogFactory implementations, not
just their own Log implementations. The default LogFactoryImpl
uses the same algorithm currently included in LogSource.
* The LogFactory implementation class can be specified by either a
system property (org.apache.commons.logging.LogFactory), or by a
corresponding property in a "commons-logging.properties" file found
somewhere in the class path.
* LogFactory implementations possess optional configuration attributes,
which are preloaded from the "commons-logging.properties" file if it
is found. These can be used by the factory to customize its own
behavior as needed.
* LogFactory and Log implementation classes are loaded from the
thread context class loader (if it is set) in a JDK 1.2 or later
environment. Hwoever, the entire API and default implementation should
still work on a JDK 1.1 system.
* A specialized exception (LogConfigurationException) is thrown for things
like missing LogFactory or Log implementation clases. This class
extends RuntimeException, so you normally don't have to put everything
in try/catch blocks unless you care about dealing with this in a
special way.
For applications currently using the pre-release version of the API, this
will typically mean replacing calls like this:
Log log = LogSource.getInstance("foo");
with calls like this:
Log log = LogFactory.newFactory().getInstance("foo");
unless you want to take advantage of the new capabilities.
If this factory approach is accepted, I propose that we take the actions:
* Deprecate LogSource (but leave it there for now, to assist existing
applications in their transition)
* Consider adding a setLogFactory() method to the Log interface -- and
the existing implementation classes -- to give them easy access to the
configuration attributes associated with the factory.
* Add unit tests for the new code (it's not really been tested yet).
* Propose the revised APIs as Commons-Logging 1.0 so that apps waiting
for a final release can know what API to depend on.
Follow-up technical discussions on this proposal should take place on
COMMONS-DEV. (If you want to argue about who can vote for what, please
start your own thread someplace else so we can get some work done :-).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138856 13f79535-47bb-0310-9956-ffa450edef68
The code that this was based on was posted by Paulo Gaspar with a Java
package name of "krankikom.log.*" -- not exactly rousing evidence of
the fact that it came from Avalon.
Finally found the old mail message, and it did have Berin and Peter
as authors. Sure wish Paulo wouldn't arbitrarily change package names ...
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138848 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
Craig R. McClanahan