On 8/8/15 5:49 PM, James Carman wrote: > Yep, same thing I said back in the day. Would we want it to be a true > "interceptor" or more of a "listener"?
Actually, we are probably talking about two different things here, unless interceptors also get pool lifecycle events[1]. Most pool logging should happen on events triggered by the pool itself (destroying abandoned instances, validation / activation failures, exceptions from factory methods, etc.). Interceptors would not be involved in this, as they just proxy method calls on pooled objects. They might do some logging as part of their function (e.g., log method calls that take a long time or have certain arguments); but I don't see interceptors (at least the way I am looking at it now) as providing a full solution for pool logging. I think pool event listeners are also worth investigating separately from this. Phil [1] At first I thought interceptors should be able to register interest in pool events as well as method invocations on pooled objects. After playing with it a little, I concluded that that would be mixing concerns. Also, there is no need for proxies for the pool lifecycle invocations. If we want to enable this, we should enable it directly - e.g., enable custom activators, passivators, validators to be plugged in or chained. > > On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz <phil.ste...@gmail.com> wrote: > >> On 8/8/15 5:04 PM, James Carman wrote: >>> We talked about this a while back with respect to logging,, having a >>> PoolListener interface or something. >> Right. That could be one use. The nice thing there is the >> interceptor could bring in whatever logging / event propagation >> infrastructure it wanted to use. >> >> Phil >>> On Sat, Aug 8, 2015 at 7:36 PM Phil Steitz <phil.ste...@gmail.com> >> wrote: >>>> Tomcat's jdbc-pool has an interceptor feature that allows custom >>>> code to be inserted into methods called on connections managed by >>>> the pool. In [pool], we have the core infrastructure to support >>>> this in a generic way via the ProxiedObjectPool. I propose that we >>>> extend this to allow users to configure interceptors to be called >>>> when registered methods are invoked on checked out objects. I >>>> haven't really thought through how configuration would work, but >>>> basically clients would register methods and possibly interceptor >>>> properties and the interceptors would get references to the method, >>>> arguments, pool and pooled object. Configuring interceptors in a >>>> GOP or GKOP would cause it to be wrapped in a ProxiedObjectPool. >>>> Eventually, we could use this [pool] capability to enable the kind >>>> of thing that jdbc-pool provides with its interceptors in DBCP. >>>> With [pool] itself, I could see providing method stats collectors, >>>> abandoned timer reset (avoiding having to implement use()) and maybe >>>> a pooled object properties cache. If there are no objections, I >>>> will open a JIRA and start experimenting. >>>> >>>> Phil >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
