with decent names is generated (link to come)
o made all the projects use a LICENSE.txt file. one this doesn't wig
out windows users and the checkstyle report likes to have one to
make sure that all sources files have a license present so if they
don't it can be reported.
o using the reactor tag in its first forms to provide a mechanism
to build the entire commons (still problems with detecting
JDK 1.4) and to generate a site where the navigation is gleaned
from the project themselves and don't have to kept in sync
manually.
o added a little front-end site deployer.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138901 13f79535-47bb-0310-9956-ffa450edef68
with me on all the details, so feel free to raise issues/add your own ideas, etc. If we have
conflicting ideas, that's probably OK as long as the pros/cons are presented along with
differing opinions.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138898 13f79535-47bb-0310-9956-ffa450edef68
default appender.
I still have some problems with log4j's JMX if I construct the logger
via API ( i.e. no log4j.properties ) - but that shouldn't affect too
many people, so I'll leave it.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138888 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
- if no log4j.properties is found, we'll construct a 'sane' config ( to be
consistent with the other loggers ). The appender must have a name ( otherwise
the JMX stuff in log4j will complain )
- fix the class name for the log4j factory
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138886 13f79535-47bb-0310-9956-ffa450edef68
( we should probably add the other loggers - only what is found is used,
it doesn't hurt anyone ).
Even if most containers will automatically add whatever is in lib, if you
use it in command line things are more difficult.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138885 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
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
> I've updated the Log4JCategoryLog.java to use the Log4J method Category.log
> () which allows the fully qualified class name (FQCN) of the user's logger
> class to be passed through into Log4J. In this case the logger class FQCN
> will be "org.apache.commons.logging.impl.Log4JCategoryLog". This allows
> Log4J to correctly identify the location in the code from which the logger
> is being called, if required. Without this Log4J reports that the calling
> location is ALWAYS Log4JCategoryLog.java:132.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138878 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
a loader, and the thread loader is set to point to a different
loader that doesn't include logging ( or to a wrong value ).
This happens when logging is used in certain container components,
where the thread loader will point to an app that may not
have/use logging.
XXX What's the right order ? From a 'feature' point of view,
it's better to try the thread loader first, so apps can
override the default. From a security point of view,
we should try the Class.forName() first, i.e. whatever
is loaded in the parent loader.
The current fix leaves the original order ( with thread loader
used if available ).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138874 13f79535-47bb-0310-9956-ffa450edef68
A bit of change in reading the properties - I spent some time trying to
understand what was the original intention, it was quite tricky. If the
property is not set, the old code would have defaulted everything to
true.
Added a bit of code to display only the last component of the log name,
logs without log name are hard to trace back to the source, and the full
name can make things hard to read ( at least that's my experience so
far ).
Of course, feel free to change back, I'm just trying to get things
a bit easier to use 'out of box', config can override anything.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138868 13f79535-47bb-0310-9956-ffa450edef68
