[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