[Biojava-l] Logging in BJ3

[Andy Yates]

As far as I was aware JPA has no concept of EJB3 interceptors. If you
want that kind of thing I think you would have to start using AOP or
proxy objects.

Andy

Mark Schreiber wrote:
> 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/
>>
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-l