> -----Original Message-----
> From: Schweizer Andreas [mailto:[EMAIL PROTECTED]
> Sent: 31 May 2005 11:25
> To: 'Log4NET User'
> Cc: Borlet-H�te Alain
> Subject: RE: A couple of questions and comments
>
> Hi list, hi Ron!
>
> first, thank you Ron for your detailed answer.
>
> > It sounds like designing and implementing your own interface (using
> > ILog as a guide) might suit your needs better. Here is an
> example of
> > an
>
> That's exactly true. If I understand it correctly, we can
> then simply provide our own customized ILog, LogImpl and LogManager.
> That's really nice :-)
You can use two different implementations to provide the CLS and non-CLS
compliant versions, with the non-CLS version subclassing the CLS one. You can
have as many LogImpls side-by-side as you like.
You don't have to use an interface like ILog you can expose the implementation
class directly (i.e. the equivalent of the LogImpl). If you are building your
own implementation then you may not need the flexibility of a interface.
Exposing the class rather than wrapping it in an interface should give you a
tiny performance improvement as the JIT will know more about what is going on.
> > Don't you think code like this would be difficult to maintain?
> >
> > log.FatalIf(temp, "Hello World");
>
> One would typically write
> log.WarnIf(room == null, "No room defined for ...");
>
> simply as a "syntactic sugar" replacement for
> if (room == null) {
> log.Warn(...)
> }
>
> There are already plenty of locations in our code where we
> use conditional calls. But with an own ILog, LogImpl,
> LogManager, we can address that :-)
Absolutely the right way to do this.
> - the first is how the constructor of LocationInfo determines
> the user method that invoked the logging command:
> System.Reflection.MethodBase method = locationFrame.GetMethod();
>
> StackFrame.GetMethod() is about ten times slower than
> MethodBase.GetCurrentMethod() (see our performance test at
> the end), so passing the latter as an argument into the
> logging method could be an interesting option, like in
>
> log.Error(MethodBase.GetCurrentMethod(), "xxxxx");
The LocationInfo is really a lazy way to extract the caller location. It must
not be relied upon because the JIT does not guarantee to preserve the whole
stack in a release build. As you point out there are more performant ways of
getting the method object if you pass the burden onto the caller. A custom
LogImpl could accept the MethodBase and store it in an event property which
could be accessed by a custom pattern layout.
There is a trade off between outright performace and ease of use.
> - and the second one is in LoggingEvent to get the user name:
> WindowsIdentity windowsIdentity = WindowsIdentity.GetCurrent();
>
> People who need the user identity in their log message could
> add it as a context property. Like this, you could avoid the
> negative impact on those who don't need it.
The WindowsIdentity.GetCurrent is only generated on demand. i.e. when using the
%w or %username patterns in the PatternLayout. It is also included in the XML
layouts and there it is not optional - to remove it you would need to write a
custom XML layout.
Otherwise it should not have any other impact.
Cheers,
Nicko
------------
Nicko Cadell
log4net development
http://logging.apache.org/log4net
