[kepler-dev] Logging frameworks in Kepler

Matthew Brooke brooke at nceas.ucsb.edu
Sun Dec 4 13:26:55 PST 2005


Sorry for my redundant email - when I saw Christopher's email, my email 
client hadn't downloaded your response. Damn this technology!!

:-)



-- 

---------------------------------------------
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:
> Christopher,
> 
> Commons-logging is very very small.  There have been some complaints
> about it in the past when used in dynamic deployment environments (like
> Tomcat).  I think most of those issues had been worked around.  There
> are two big benefits of using commons logging:  1) it automagically
> loads & configures the back end logging services.  Without using JCL you
> need to write some 5-10 lines of code at application start up in order
> to find & load the config file, etc.  Granted that's not a big deal, but
> in this case, we didn't need to mess with trying to find the best place
> in ptolemy to do this.  Benefit 2) it provides a common java-side api to
> various logging systems (log4j and jdk 1.4).  When jdk 1.4 came out,
> there were some complaints (at least in my group at the time) that if
> Sun were going to bother with a logging system, the should at least make
> it as functional as log4j.  It is a slightly weaker system but as you
> said it is always there.
> 
> In any case, the Kepler dependencies require the use of both commons
> logging and log4j.  Commons logging is required by HP Jena, Apache Axis
> among other things.  And log4j is required by ...  I cannot recall right
> now.  Anyway, since Commons Logging will find log4j in the class path,
> in our deployment, it will always use log4j.  In a pure Ptolemy
> deployment, you could configure and use jdk1.4 logging.  The fun thing
> is, if you use commons logging, then the logging messages in ptolemy
> (which for you use the jdk1.4 backend) will be configurable in Kepler
> using log4j.properties.  If you use the jdk1.4 api directly, then we're
> stuck and have to configure two seperate logging systems.
> 
> You other question, about where does stdout go when you click on an
> icon...  Well, I don't realy know.  In the unix world, I suspect it goes
> to /dev/null.  If you're really clicking on a sh script or bat file,
> then you can control where stdout goes.
> 
> But if you use a logging system such a log4j or jdk 1.4 (or use the JCL
> wrappers) then you can in the configuration file control where these
> messages go.  You can direct them to both stdout/err and to a log file. 
> And you can even have the formats different for the two destinations.
> 
> Kevin
> 
> Christopher Brooks wrote:
> 
>> 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
>> --------
>>  
>>
> 
> 


More information about the Kepler-dev mailing list