(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
for debug. This way if commons-logging needs to define a lower level,
it will be able to do so. I am thinking about this because JBoss has
a TRACE level below debug.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138847 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
