[Biojava-l] Logging in BJ3

Andy Yates ayates at ebi.ac.uk
Tue Oct 21 08:40:48 UTC 2008


Hi,

A logging framework is a priority to start baking into the new API now.
As Mark has mentioned logging frameworks are very flexible things but
it's not until you start using them do you get a real feel about how
easy & extensible they are.

The JDK logger has some good integration with MessageFormat &
localization. I'm not completely taken with how it does the checks for
log levels (log.isDebugEnabled() just seems easier that
log.isLoggable(Level.FINEST)) & how you grab a logger ( I'd prefer
something like Logger.getLogger(this.getClass()) ) but that's just
nit-picking.

I'll be happy to go with whatever people are most comfortable with & we
should attempt to use as many of the core Java classes as possible.

Andy

Mark Schreiber wrote:
> Hi -
> 
> I would like to strongly advocate the liberal and extensive use of
> Logging in BioJava3.  The lack of this plagued us (me at least) during
> bug fixes in previous versions of BioJava.  The default Java logging
> API is very flexible and easily meets our needs. It's also not too
> much effort for developers to put in place (you know you use
> System.println() all over the place anyway).
> 
> The following is an example snippet using logging that would certainly
> help debugging.  With the standard logging setup only the severe
> statement would appear on the terminal. We could also provide config
> files that show lower levels of logging so that people can easily
> generate detailed logs to accompany bug reports.  If we want to be
> really tricky we could even use a MemoryLogger that has a rotating
> buffer of log statements that could spit out with a stack trace so you
> could just submit the stack trace and the activity log all in one go
> and we can get an idea of what was going on at the time.
> 
> The example below also shows what to do to avoid a major performance
> hit during logging. The marked "expensive logging operation" pretends
> to get config information by getting it from a database. One might
> expect this to take time while the db connects etc and could produce
> quite a long String of information. To save time when logging is not
> set to the CONFIG level the if statement is able to skip this costly
> step.
> 
> I know from experience we will definitely get the most value from this
> in the IO parsers and ThingBuilders.
> 
> Any thoughts?
> 
> - Mark
> 
> 
> 
>     private Logger logger = Logger.getLogger("org.biojava.MyClass");
> 
>     public Object generateObject(String argument){
>          logger.entering(""+getClass(), "generateObject", argument);
> 
>          //expensive logging operation
>          if (logger.isLoggable( Level.CONFIG )) {
>             logger.config("DB config: "+ getDBConfigInfo());
>          }
> 
>          Object obj = null;
>          try{
> 
>             //do some stuff
>             logger.fine("doing stuff");
>             obj = new Object();
> 
>          }catch(Exception ex){
>              logger.severe("Failed to do stuff");
>              logger.throwing(""+getClass(), "generateObject", ex);
>          }
> 
>          logger.exiting(""+getClass(), "generateObject", obj);
>          return obj;
>     }
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-l



More information about the Biojava-l mailing list