[Biojava-l] Logging in BJ3

[Mark Schreiber]

For the Entity classes my original thinking was to implement an EJB3
interceptor which logs all method calls. This would be preferable to
putting logging statements in all the classes but I don't know if such
an interceptor will work outside of a container. Does anyone know if
JPA can use an interceptor outside of a container?

Logging for the actual persistence would be via the persistence
provider (Hibernate, Toplink etc).

- Mark

On Tue, Oct 21, 2008 at 5:08 PM, Richard Holland
<dicknetherlands at gmail.com> wrote:
> Excellent idea. I'll integrate it into ThingParser as an example
>
> 2008/10/21 Mark Schreiber <markjschreiber at gmail.com>
>>
>> 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
>
>
>
> --
> Richard Holland, BSc MBCS
> Finance Director, Eagle Genomics Ltd
> M: +44 7500 438846 | E: holland at eaglegenomics.com
> http://www.eaglegenomics.com/
>