Yep, same thing I said back in the day. Would we want it to be a true "interceptor" or more of a "listener"?
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 > >
