"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/10/2004
04:34:07 AM:
> 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.
We considered binding the class name to the Log object. Yes, we *may*
have the class name in the form of a category name, but further discussion
convinced us that users of logs do not necessarily use class names for
category names, I know of a number of exceptions to that myself. Also,
for those that use alternate category names, do we really want to force a
one Log instance for every class, even when the category name is common?
We felt like this was unnecessarily complicated, had a number of runtime
lifecycle concerns. We left the Log instance bound to a single category.
>
> > - 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.
The intent was to facilitate obtaining loggable error/warning information
to be logged AND use the same information in an exception.
However, you raise a very good point.
Other comments on this?
>
> [...]
>
> > - 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.
Well... we didn't exactly miss it. We did discuss it, there are clearly
advocates for such.
That said, Commons Logging has strongly resisted this for some time.
Please put commons logging into the context of a component level log
wrapper, it's not an application level logging mechanism [commons logging
bridged the component logging TO your application logger].
You are claiming that you want to be able to configure the logging of a
component as it pertains to your application. As a component developer, I
would resist this... When I tell my component users to 'turn on logging',
then I *WANT* logging on, I want deterministic behavior, I don't want to
worry about how they've configured the component level logging.
>
> Regards
> Henning
>
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
