[kepler-dev] Logging frameworks in Kepler

[Christopher Brooks]

Looking at logging is a great idea.

If I'm running an application by clicking on an icon, where do the log
messages go? 

We've had a ton of problems in Ptolemy where there is a nice error
message printed to standard out, but the error message is either
lost or obscured.

Log messages are a similar sort of issue, though not as critical.

I'd probably slightly prefer to see vanilla Sun Java 1.4 logging used
without the overhead of using Apache Jakarta Commons Logging or
log4j. The reason is that Java 1.4 logging will always be there, which
could be useful for deploying smaller Java programs in a distributed
fashion.

I don't feel that strongly about this, just vaguely.

Ptolemy needs to do more with logging.  Revamping how
we listen to actors and directors could be useful.

_Christopher



--------

    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 method
   s:
    > 
    > 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 trac
   e.
    > 
    > 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
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------