The application I'm working on consists of a Core project and several sub-projects. The sub-projects have a reference to the Core project. We didn't want to require each of the sub-projects to have a reference to log4net. The thinking behind that was what if we wanted to change out loggers or upgrade to a new version of log4net? We didn't want to have to go through and update references and code in each of the sub-projects. Our application has grown to include pluggable modules. We didn't want module(s) built against a specific version of log4net. At one point we thought about making a LogFactory that would return instances of our custom ILog so the logger could be specified at start-up but that has been put on the back-burner*. I think I saw code for that somewhere in NHibernate or the .Net Spring Framework. While I see some merits in that, I don't want to write .Net commons-logging. I'd just as well build things directly against log4net but with the amount of sub-projects we have, I think the way we did things makes sense.
Getting back to log4net.ILog, we don't want to add additional members to the interface or provide additional functionality. We just want to abstract it away one more so ILog resides in Company.Project.Core.Logging.ILog and everything uses that. My original question about implementing ILog and 1.2.9 beta was that we're still using 1.2.0 beta 8 and I wanted to make sure there wasn't a drastic change on how things were done between our version and the new one. After reading your reply, I think we're ok. One of the nice side effects from doing things this way is that when 1.2.9 beta came out with its xxFormat members, I was able to incorporate that into our ILog interface even though we were/are still on 1.2.0 beta 8. When I saw this patch: http://marc.theaimsgroup.com/?l=log4net-dev&m=111161599830698&w=2 it was easy to update our code as well. I don't think we're doing anything terribly ground breaking. Have other people ran into this problem? Nicko's post on the SourceForge forums was the only place I've heard this problem mentioned. Is there a better way we should be doing things? - Ron * - I've always wanted to design a product that comes with its own ILog interface and default NopLogger ILog implementation. Then at run-time if the application sees there is log4net.dll available, load and use that in place of the NopLogger. --- Nicko Cadell <[EMAIL PROTECTED]> wrote: > If you need further clarification it may be helpful to briefly > outline > what does your custom extension does, or what custom APIs does it > provides.
