Ron, Nice thought.
Let me be the devil's advocate here... The first thing that would happen is we will get a request (or an urge) for transparent externalization of the "objects" and "events" that would be implicitly logged.. say via an extension to log4net config file. Then there will be another (urge/request) for extending that concept and use some sort of internal AOP framework (ex: Castle Dynamic Proxy) to extend the implicit logging through external definition for other user defined objects (as long as they follow the needs for the said AOP framework.. ex: interfaces.. non sealed classes for castle). Eventually we will enter the realm of a long list of enhancement requests (and debate) till we end up with requirements for a true aspect oriented implementation (static or dynamic weaving) of log4net/nlog. And obviously we can never get to true dynamic pointcuts and joins with the current .NET model because there is no (reasonably performant) way for us to perform true runtime instrumentation. :-) But.. leaving aside my cynicism.. if we can curb our enthusiasm and stick to the basics (flexible yet performant logging), we can bleed in good additional functionality into log4net/nlog by walking down the path you are suggesting. Regards, Kiran Raja. Ron Grabowski <[EMAIL PROTECTED]> 04/18/2005 03:15 PM Please respond to "Log4NET User" <log4net-user@logging.apache.org> To Log4NET User <log4net-user@logging.apache.org> cc 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. The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
