It should be very straight forward to build a proxy that will wrap any interface and log all method calls and return values. While I can certainly see this as a very useful sample of a way of using log4net I am not too sure about it being a built-in component. I have built such things in the past, however I have usually been disappointed by the performance impact of the proxy.
If someone wants to look into this further then it is probably best to continue this on the log4net-dev list (http://logging.apache.org/log4net/contributing.html). Cheers, Nicko > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: 18 April 2005 20:15 > To: Log4NET User > Subject: More things a logger should (or shouldn't?) do. Was > RE: Buffer Flushing and Table Maintenance in the ADONetAppender) > > Since we're on the subject of things a logger should or > shouldn't do, what are people's thoughts on having the logger > (log4net, nlog, etc.) automatically log certain well-known > .Net objects (or Interfaces) such as IDbCommand and > IDbConnection via code proxy? I've used the IBatis libraries > in some Java projects as part of my data access block: > > http://www.ibatis.com > > One thing it does a very good job of is automatically logging > what is sent and received from the database. Translated to > .Net, if I had a IDbCommand object: > > IDbCommand cmd = GetCommand(); > > I could wrap a code proxy: > > http://www.castleproject.org/castle/show/dynamicproxy > > around it like this: > > cmd = log4net.Proxies.IDbCommandLogProxy(cmd); > > so whenever I queried the database: > > IDataReader reader = cmd.ExecuteReader(); > > The following information would be sent to the log files > automatically without any additional code on my part: > > DEBUG - {IConnection-100007} Connection Open DEBUG - > {IDbCommand-100008} CommandText: SELECT UserId FROM User > WHERE Login = ? > DEBUG - {IDbCommand-100008} Parameters: [abc123] DEBUG - > {IDbCommand-100008} Types: [Sytem.String] DEBUG - > {IDataReader-100009} ResultSet DEBUG - {IDataReader-100009} > Header: [UserId] DEBUG - {IDataReader-100009} Result: [4] > DEBUG - {IConnection-100007} Connection Close > > Of course you could turn that on or off at runtime. Yes, it > would probably slow something down. I'm not too concerned > with that becuase I always have line numbers (%L) turned on > in my appenders anyway during development. Yes, it would > generate _a lot_ of log messages. > > I've been having a conversation with myself :) on the IBatisNet Jira > server: > > http://issues.apache.org/jira/browse/IBATISNET-35 > > Thoughts, comments? Cool, not cool? > > Thanks, > Ron > > --- Nicko Cadell <[EMAIL PROTECTED]> wrote: > > > I agree with Ron on the scope of the AdoNetAppender. The database > > provides wonderful tools to manage the data stored: stored > procedures, > > triggers, and DTS packages (or equivalent). I happen to > think that in > > production the AdoNetAppender should connect to the database with a > > restricted account that only allows execution of a single stored > > procedure that logs an event. >
