Richard Sitze <[EMAIL PROTECTED]> writes:
Hi,
> B.2. Fix fragile configuration problems - Currently
> the user has NO idea which impl is in effect.
> All the default/fall back behavior means that in
> the end we have an apparent non-deterministic
> logging implementation. Errors in config file
> names, classpath errors, classpath ordering,
> etc., can all change the behavior... with no
> idea which is in effect.
> The fundamental problem with the current factory
> is that it is dependent on "passively"
> identifying a logging implementation.
> We propose one solution below, but would ask a
> more general question: any new bright ideas?
+1 It could be as simple as providing a property in
commons-logging.properties which says "use.classpath.detection = no"
If the commons-logging.properties is omitted or the property is missing,
then still the (fragile) class path checker is used.
> - For message level logging, support globalized
> variants on the new EnterpriseLog interface:
> info(Class callingClass,
> String methodName,
> String messageID);
-0 on callingClass. Reason for this:
Many of the log using applications have the calling class anyway. They
use a pattern like this:
Log log = LogFactory.getLog(this.getClass());
So you might already _have_ a class object. If the log is obtained by
the
Log log = LogFactory.getLog("foo.log");
pattern, we can still add a
log.setLogClass(this.getClass());
method which is completely optional. But you get one less parameter to
pass (which will be this.getClass() most of the time anyway) and if
you have a lot of logging statements, this will either evaluate to
having to drag another object (which contains the Class object of the
current class) around or a lot of this.getClass() method calls.
> - Utility function to support formatting for
> other purposes (exception strings):
> formatMessage(String messageID);
> formatMessage(String messageID, Object messageParam);
> formatMessage(String messageID, Object[] messageParams);
Strictly -1. This is not the scope of commons-logging! We could add
this to some other commons project. Once we add non-logging
functionality to commons-logging, people will start using this for
non-logging related purposes.
[...]
> - Repackaging
+1 on that.
One thing that you have missed and that I would like to see is
programmatic change of the log level to be used. I have no real idea
yet on how to do this but I really would like to be able to change the
log level of a log statement e.g. from INFO to WARN without having to
do source code changes.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
