Ron, It sounds like you have done the right thing for your requirements. You can essentially just copy the ILog interface, the LogImpl class and the LogManager class into your own project and use your version instead.
You may want to dispense with the ILog interface altogether and just return strongly typed LogImpl (or you could rename this to Log) objects. If your Log object is sealed and its methods are not virtual then your should get a small per-call performance boost by doing this. The improvement will be small so it may not be worth changing your existing code. As far as providing a logging fa�ade that allows different logging implementations to be selected at runtime the log4j project has setup a separate slf4j - Simple Logging Facade for Java (www.slf4j.org) project to combine the efforts of the log4j team with the commons-logging team. I think that this will provide a useful design pattern if we need to go in that direction. Cheers, Nicko > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: 16 May 2005 20:45 > To: Log4NET User > Subject: RE: Wrapping LogManager to make ILog not rely on log4net.ILog > > 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. >
