[kepler-dev] Logging frameworks in Kepler
Kevin Ruland
kruland at ku.edu
Sun Dec 4 11:11:02 PST 2005
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