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 > <[EMAIL PROTECTED]> wrote: >> Excellent idea. I'll integrate it into ThingParser as an example >> >> 2008/10/21 Mark Schreiber <[EMAIL PROTECTED]> >>> 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@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: [EMAIL PROTECTED] >> http://www.eaglegenomics.com/ >> > _______________________________________________ > Biojava-l mailing list - Biojava-l@lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/biojava-l _______________________________________________ Biojava-l mailing list - Biojava-l@lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/biojava-l