> 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
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
a logger package, and preferably use a specialized factory, which
can provide better integration with the real logger.
The introspection is ok, but it's limited and complex.
Also, switch to SimpleLog by default - which is almost the same as
using System.err.println(). If common logging requires the user to set
properties and configurations to get the same behavior as System.err(),
why would anyone use it ?
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138867 13f79535-47bb-0310-9956-ffa450edef68
to the logger impl, without introspection. The factory can be extended
to take advantage of other log4j features ( it calls getInstance(Class)
direclty for example ) to integrate better.
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138865 13f79535-47bb-0310-9956-ffa450edef68
to use the standards ( if it makes sense ), and that's something that
works well enough ( crimson, xerces, xalan, saxon, etc).
Changed the code that deals with 'properties'-based setup. The propertis
will be set on the factory regardless of the discovery mechanism.
This may be arguable, but at least it's symetrical and permits the
application to pass the information to the logger implementation in
all cases. Given that the properties are read by the class loader,
each application can have it's own settings (even if
the admin sets a JVM-wide default by using a system property ).
git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@138862 13f79535-47bb-0310-9956-ffa450edef68
Costin Manolache