[kepler-dev] Logging frameworks in Kepler

[Matthew Brooke]

Thanks Kevin - nice work! If anyone needs a brief intro (or reminder) 
for which logging levels to use (without having to RTFM :-), here's a 
short summary I wrote in a previous lifetime:

-----------------

You can debug using one of 5 methods, depending on the level of severity:
   log.fatal(String msg);
   log.error(String msg);
   log.warn(String msg);
   log.info(String msg);
   log.debug(String msg);

Severity levels are as follows (in decreasing order of severity and 
increasing frequency of usage):

FATAL level designates very severe error events that will presumably
       lead the application to abort.
       EXAMPLE >> Use this just before you do a System.exit(1)

ERROR level designates error events that might still allow the
       application to continue running.
       EXAMPLE >> Use this when you catch an exception

WARN  level designates potentially harmful situations.
       EXAMPLE >> If something happens that isn't critical, but may make
       the software misbehave

INFO level designates informational messages that highlight the progress
       of the application at coarse-grained level.
       EXAMPLE >> When "milestone" events occur. This would be the
       default level for development when not debugging. Show restraint
       when using "info" - otherwise printouts cause information overload

DEBUG Level designates fine-grained informational events that are most
       useful to debug an application.
       EXAMPLE >> use for all other printouts of minutae that are
       interesting only to someone who is specifically debugging the app.
       Preferred level, unless you have a good reason for going higher.


-- 

---------------------------------------------
Matthew Brooke, Ph.D.
Marine Sciences Research Building, Room #3407
University of California
Santa Barbara, CA  93106-6150
ph: (805) 893-7108   fx: 805-893-8062
brooke at nceas.ucsb.edu
---------------------------------------------


Kevin Ruland wrote:
> Hi.
> 
> As some of you know, we are using some 3rd party jars which require use
> of the Apache Jakarta Commons Logging
> http://jakarta.apache.org/commons/logging/index.html system.  In
> particular this package is required by the Jena code used within SMS. 
> To make a long story short, we have the facilities to do runtime
> configurable logging so we might as well take advantage.
> 
> Towards this end, I played around with this a little this morning and
> have found a way to use and configure it when running Kepler.  There are
> two parts required to use it:  the java code must use the proper API
> when issuing logging messages, and the runtime system must have access
> to the proper configuration files.
> 
> Commons logging is a unified api to mutliple backend logger
> implementations.  It supports log4j, jdk1.4 built in logging, and a
> couple of others.  Since we have to have log4j (used by other jar files)
> this is the most natural back end to use.  In order to have
> commons-logging configure log4j you only need to have a log4j.properties
> file in the classpath.  One easy place to put this is in build/classes
> and it will be loaded when you do ant run-dev.  I have gone so far as to
> change my build.xml to automatically copy this file to the correct place
> each time I do a run-dev.
> 
> I have committed a simple log4j.properties file which can be used as an
> example.  This particular file logs to CONSOLE (stdout) and only logs
> messages with priority > WARN (warn, error, fatal).  It formats the
> messages nicely.  You can peruse
> http://logging.apache.org/log4j/docs/manual.html to learn a little more
> about log4j if you wish.  You can adjust the log verbosity by changing
> the default log level (first line), or you can change it for particular
> categories of log messages.  I have found Jena to be very noisy (and not
> helpful) so I put this line in my local log4j.properties:
> 
> log4j.logger.com.hp.hpl.jena=WARN
> 
> Finally, to use Commons Logging in a java class you need to:
> 
> 1) Import the commons logging classes.
> 
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> 
> 2) In the class create a static variable to hold the logger:
> 
> private static Log logger = LogFactory.getLog( <category> );
> 
> here <category> is a string which represents the logging category.  Many
> people like each java class to define a different category so you would
> replace <category> with Classname.class.getName().  However, it might be
> beneficial to have multiple classes log to the same 'logical category'
> in which case all those classes should use the same category string. 
> For example, Matthew's xml/svg icon stuff might want to log everything
> to a single category called "org.kepler.XMLIcons".  Or whatever.
> 
> 3)  Whenever you want to issue a diagnotic message call the logger methods:
> 
> logger.debug( "Here is a debug message");
> 
> The commons-logging user guide
> http://jakarta.apache.org/commons/logging/guide.html has some
> suggestions about using code guards when the arguments require some
> computation, and also lists the available logging methods.  These
> methods take either an Object (on which it calls toString()), or an
> Object and a Throwable.  The Throwable will be used to print a stack trace.
> 
> I think runtime configuration of logging is in generate A Good Thing
> (tm) and can help people focus on the problems in specific pieces of code.
> 
> Kevin
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev