[kepler-dev] Logging frameworks in Kepler
Matthew Brooke
brooke at nceas.ucsb.edu
Sun Dec 4 13:23:54 PST 2005
Hi Christopher
> If I'm running an application by clicking
> on an icon, where do the log messages go?
Log4J uses a properties file to specify one or more "appenders", which
is the term it uses for logging destinations. Numerous appenders are
available, including an appender for sending output to the console, one
for writing output to a log file etc - and if you are so inclined, you
can create your own appenders too, to log anywhere you want (database?
web service? gmail account?? :-).
The config file also allows you to specify the format of the logging
printout (and you can include lots of information in addition to the
String message being logged, if you wish - for example the classname,
method, line number, time, etc). You can also filter by severity and/or
by package name or other identifier.
> 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.
My understanding is that the commons package provides a standard API,
which can then allows you to plug in one of several implementations
(Java logging packages, Log4J or others?), thus allowing the flexibility
of easily changing which implementation is used, without needing to make
changes to code. Kevin can probably provide more info about this, since
I've really only used Log4J in the past. I think Kevin's rationale for
using Log4J was that it has to be shipped with Kepler anyway, since some
of the actors depend on it; however, you make a good point, and I don't
think it would be a big deal to adopt the Java logging framework
instead. We should just make a decision one way or the other asap,
before too much code gets written.
Kevin - can you lend some wisdom to the mix, since you have a better
overview of the Apache Commons stuff, etc?
m
--
---------------------------------------------
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
---------------------------------------------
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