netcommon-developer — Discussion on the development of the netcommon libraries

[Netcommon-developer] Feature Request 3058829 - Add Log(LogEvent le) method to ILog

[Geoghegan, W. A (Willie) <wil...@in...>]

Common.Logging - Here is some additional information about this request
and what I have implemented since I first filed it.

I filed this request.  The idea is that I would like a method on the
ILog interface that would take a "LogEvent"-type class/structure (NLog
equivalent is LogEventInfo, log4net equivalent is LoggingEvent (or
LogginEventData)).  My specific purpose is to log a log event that I
receive over the wire in a WCF logging service (which is - or could be -
implemented in terms of Common.Logging).  The most important thing for
me is to allow the "client" to capture context information (e.g. time of
message, user/machine/thread info, etc) that will not be available  in
the service.  The "client" can put all of that information in some kind
of "LogEvent" class (maybe just a LogEvent DTO) and send that to my
logging service.  By maintaining all of the logging information as
properties rather than just sending the formatted message to the logging
service, I still have the option of specifying the formatting in the
service (or the configuration thereof) or having the service send the
information to a database.  For my own purposes, I have specified a
separate interface, ILogEvent, and have implemented it on my own version
of the NLog and log4net abstractions.  Inside of my service, I request
the logger corresponding to the logger name in the LogEvent, then try to
get the ILogEvent interface from the logger.  If the logger supports the
interface (i.e. as of today, if it is my implementation) then I take the
properties from the logging service LogEvent DTO, create a "LogEvent"
object and pass it to the ILogEvent.Log method.  Inside the
ILogEvent.Log method, depending on whether it is the NLog or log4net
implementation, the information is transferred to the corresponding
LogEventInfo or LoggingEvent object and then logged using the underlying
logging framework's Log method.

So, I have something like this:

//Mostly an intersection of the corresponding NLog and log4net objects
public class LogEventData
{
  public DateTime DateTime { get; set; }
  public Common.Logging.LogLevel Level { get; set; }
  public string LoggerName { get; set; }
  public string Message { get; set; }
  public Exception { get; set; }

  private IDictionary<string, string> properties;

  public Properties
  {
    get
    {
      if (properties == null)
      {
        Properties = new Dictionary<string , string>();
      }
      return properties;
    }
  }

  //Various constructor overloads to allow the specification of most or
all of the properties.
  //The key is to allow DateTime to be set explicitly rather than always
automatically populated.
  //If a dictionary is passed into the constructor then it is cloned
into the properties field.  Cloning
  //might be necessary - or desirable - but that is what I did.
}

public interface ILogEvent
{
  void Log(LogEventData data);
}

ILogEvent is implemented on loggers.  (Alternatively,
Common.Logging.ILog could add a Log method (or more than one if
overloads are desired)).

Here is how I implemented it for a NLogLogger:

public NLogLogger : AbstractLogger, ILogEvent
{
  NLog.Logger _logger;

  //Existing NLogLogger stuff left out for brevity.

  public void LogEvent(LogEventData data)
  {
    if (!_logger.ShouldLog(data.Level)) //ShouldLog is an extension
method that I implemented for NLog.Logger
    {
      NLog.LogEventInfo info = new
NLog.LogEventInfo(data.Level.ToNLog(), data.LoggerName, data.Message);
      info.TimeStamp = data.DateTime;
      info.Exception = data.Exception;

      if (data.Properties != null && data.Properties.Count > 0)
      {
        foreach(KeyValuePair<string, string> kvp in data.Properties)
        {
          info.Context.Add(kvp.Key, kvp.Value);
        }
      }
    }
  }
}

The implementation for log4net is similar.  I have not implemented
anything for LAB since we are not considering using that.

For my purposes, this is probably sufficient.  If anyone wants this as a
general capability, it might be useful to provide a LogEventData class
that also allows for the storage of a parameters array and a format
string rather than just a message string.

FYI - the workflow where I intend to use this capability involves
logging from a Silverlight client (we will also probably want to log
from an AJAX client, probably to the same LoggingService).  Currently I
have an implementation of Common.Logging implemented for Silverlight (to
allow the same programming api for client developers as well as
desktop/server developers).  My Common.Logging.Silverlight component is
essentially a stripped-down port of your Common.Logging LogManager and
some of the infrastructure - but not the configuration part.  I can
programmatically configure two different loggers (three if you count
NoopLogger) on the Silverlight client side: SilverlightDebuggerLogger to
log to the debugger and LoggingServiceLogger to log to the
LoggingService.  LoggingServiceLogger.WriteInternal takes the logging
information (time, logger name, log level, message, any additional
context information that we want to gather), creates a LogEvent DTO, and
sends it to the LoggingService (possibly accumulating several messages
so that every logging statement does not result in a trip over the
wire).  Inside the LoggingService, the LogEvent DTO is converted to a
"Common.Logging" LogEventData object which is logged via ILogEvent.Log.
The approach is similar to Daniel Vaughn's Clog.

If you are interested in adding this capability (or something like it),
I am willing to send you what I have implemented.  Because I think that
I can get by with what I have done, I probably would not cry (much) if
you decided not to incorporate something like this in Common.Logging.

Feel free to contact me directly or via the list if you wish to discuss.

Willie Geoghegan.
 

[Netcommon-developer] Logging Context

[Geoghegan, W. A (Willie) <wil...@in...>]

Common.Logging team - I know that are busy right now, but take a look at
this when you have some time and let me know your thoughts.

I have implemented logging context abstractions for NLog and log4net
(and also for Trace.CorrelationManager.LogicalOperationStack).  For the
most part, I followed the model of Castle's logging context abstraction.
For now, I have kept it separate from the actual Common.Logging
projects.  My approach was to define an interface by which a logging
abstraction implementation (ILoggerFactoryAdapter) could return one or
more objects that wrap the underlying logging framework's context.  I
implemented a static object, LogContext, that is parallel to LogManager
which exposes the logging context.  Internally LogContext gets the
LogManager.Adapter property and tries to get the interface that exposes
the logging context.  I modified (copied and created new versions) the
NLog and log4net logging abstractions to implement the interface.  So,
when I configure Common.Logging to use my NLog adapter, for example, the
adapter is able to hand out an interface that wraps the NLog context
api.

Sample code (assumes that Common.Logging is configured to use my NLog
adapter)

LogContext.GlobalProperties["starttime"] = DateTime.Now;
LogContext.ThreadProperties["sessionid"] = GetMySession().Id;
LogContext.ThreadProperties["myguid"] = Guid.NewGuid();

using (LogContext.ThreadStacks["ndc"].Push("outer scope"))
{
  DoSomething();
  using (LogContext.ThreadStacks["ndc"].Push("inner scope"))
  {
  }
}

The net effect of these lines is that values were inserted into NLog's
GDC and MDC and two values were pushed onto (and popped from) the NLog
NDC.

Here are the interfaces that I implemented:

IAdapterContextProvider  is implemented by any adapter that wants to
expose a logging context api.  If I had modified the Common.Logging
source, I probably would have just added a Context property (as this
interface defines) directly to the ILoggerFactoryAdapter interface.

public interface IAdapterContextProvider
{
  IAdapterContext Context { get; }
}

An implementation of the IAdapterContext interface is returned by any
adapter that wants to expose a logging context api.  If something like
this is provided by Common.Logging for each delivered adapter that
supports a logging context api (NLog, log4net, etc), then I think that
the implementation should be reusable (i.e. in its own object, not as
part of an adapter implementation).  That way, if I want to make my own
NLog abstraction for some reason I could use the already-existing
context api implementation.

This interface allows for the exposure of NLog's GDC (GlobalProperties),
MDC (ThreadProperties), and NDC (ThreadStacks["ndc"]).  It also allows
for the exposure of log4net's GlobalContext.Properties,
ThreadContext.Properties, and ThreadContext.Stacks.  It does not allow
exposure of log4net's LogicalThreadContext.Properties and
LogicalThreadContext.Stacks.  My implementation mostly mimics Castle's
implementation and they did not expose the "Logical" context
information, so I didn't.  I don't know if it should be exposed
generically or not (since NLog does not have an equivalent concept).  It
might be a good idea to expose the "Logical" context on the chance that
someone wants to implement a "Logical" context similar to log4net's
(i.e. uses CallContext to store "Logical" context information) to store
context information and then implement the corresponding NLog
LayoutRenderer to output the information from the context.  I haven't
used log4net or NLog enough to have a strong opinion about this.

public interface IAdapterContext
{
  IContextProperties GlobalProperties { get; }
  IContextProperties ThreadProperties { get; }
  IContextStacks ThreadStacks { get; }
}

The IContextProperties interface exposes a dictionary-like interface
that is a very thin wrapper around the underlying logging framework's
context dictionary objects.  For some reason, Castle exposes only the
indexer.  It seemed to me that they should have also exposed to Clear
and Remove to allow for cleaning up the dictionary (don't know if this
is common, but NLog and log4net both expose Clear and Remove).

public interface IContextProperties
{
  object this [string key] { get; set; }
  void Clear();
  void Remove(string key);
}

The IContextStacks interface exposes a dictionary of context stacks.
This concept (dictionary of stacks) exists in log4net but not in NLog
(which has only a single stack, NDC).  The Castle implementation always
returns the NDC stack in the case of their NLog abstraction.

public interface IContextStacks
{
  IContextStack this[string key] { get; }
}

Should this have a Clear and/or Remove to clear or remove a particular
stack?  I don't know.

The IContextStack interface exposes a stack interface for providing a
"logical operation stack" context.  It is a thin layer over the
underlying "stack" implementation.

public interface IContextStack
{
  int Count { get; }
  void Clear();
  string Pop();
  IDisposable Push(string message);
}

Nothing really earth shattering here, except maybe for the fact that
Push returns an IDisposable, thus enabling the using(blah.Push["scope"])
syntax for providing a logical scope around some code.

Where I exposed all of these through a separate object, LogContext, I
think that it makes sense to expose them through the LogManager.
LogManager could look something like this:

public static class LogManager
{
  //GetLogger, etc ...
  IContextProperties GlobalProperties
  {
    get
    {
      return Adapter.ContextProvider.Context.GlobalProperties;
    }
  }
  IContextProperties ThreadProperties
  {
    get
    {
      return Adapter.ContextProvider.Context.ThreadProperties;
    }
  }
  IContextStacks ThreadStacks
  {
    get
    {
      Return Adapter.ContextProvider.Context.ThreadStacks;
    }
  }
}

(Alternatively, these context objects could be exposed as static objects
directly from the Common.Logging namespace (or maybe a
Common.Logging.Context namespace).  What actually gets returned could
work the same way - pull it from the current value of LogManager.Adapter
)

The assumption is that each of these properties exposed by LogManager is
never null.  A "NullContext" object would be provided (probably a
NullContext as well as null implementations of each interface).  By
default, if an Adapter does not support IContextProvider (or if the
value is null), then a NullContext would be returned (similar to the
NoopLogger and NoopLoggerAdapter).  If someone writes an adapter and can
(or chooses to) only expose some context, then that developer could
return the "null" implementation for each context that they do not
provide.  For example, if someone wrote a logging adapter for
System.Diagnostics using TraceSources, they might choose to only expose
the Trace.CorrelationManager.LogicalOperationStack (as
IContextStacks/IContextStack) and return "NullContextProperties" for
GlobalProperties and ThreadProperties.

What I have implemented actually seems to work pretty well.  I can set
the underlying logging framework's logging context values from my
application code in a manner that is similar to how I would do it if I
were programming directly against the specific framework.

Some comments:
1.  I'm not sure that I really like the ThreadStacks idea, primarily
because I don't know how often people actually take advantage of the
ability to have multiple stacks per thread (in log4net, NLog has only
one stack per thread).  That means that code that uses "stacks" is
cluttered with this pattern:

using (LogManager.ThreadStacks["ndc"].Push("hello"))
{
}

Rather than something like this:

using (LogManager.ThreadStack.Push("hello")
{
}

Having to type the key every time (and making sure not to mistype it) is
not really providing the "pit of success".  On the other hand, as soon
as only one stack is exposed, someone will ask why the context has been
"dumbed down", "I could do it in log4net", etc.  You can imagine...  I
wonder if it would be useful (or, perhaps simply more confusing) to
expose ThreadStack AND ThreadStacks.  If you are using only a single
stack, using ThreadStack would behave AS IF you had called ThreadStacks
passing the same name every time.  By definition, the name could be
"ndc" so that it would be easy to specify the stack information in the
underlying logging framework's output formatting configuration.

Maybe LogManager could expose something like this:

public static class LogManager
{
  IContextProperties GlobalProperties { get {
GetTheGlobalPropertiesFromTheCurrentAdapter(); } }
  IContextProperties ThreadProperties { get {
GetTheThreadPropertiesFromTheCurrentAdapter(); } }
  IThreadStacks ThreadStacks { get {
GetTheThreadStacksFromTheCurrentAdapter(); } }
  IThreadStack ThreadStack { get { return ThreadStacks["ndc"]; } }  //In
effect, "ndc" is the "default" stack
}

This way if you only want to use one stack, you can just use the
ThreadStack property.  If you have a need for multiple stacks, feel free
to use the ThreadStacks property.

2. I'm not 100% comfortable with leaving out log4net's LogicalContext
information (like Castle did). With threading and parallel programming
becoming more and more important, it certainly seems useful to have this
arguably more powerful option for maintaining logging context.
Log4net's LogicalContext.Properties is implemented using a CallContext
(as opposed to Thread.SetData which is used to implement log4net's
ThreadContext.Properties and NLog's MDC).  Theoretically this allows for
the logical properties to be propagated along the call sequence, even
over remoting boundaries.  I'm not sure if this really happens because
log4net uses CallContext.SetData rather than LogicalSetData and log4net
does not implement ILogicalThreadAffinaty (or whatever the interface is)
on the dictionary that they store in the CallContext.  On the other
hand, NLog does not have a similar concept, so what would the
implementation of LogicalThreadProperties for it be?  Would it delegate
to ThreadProperties?  Would it do nothing (NullContextProperties
implementation)?  Could a CallContext-based implementation be provided
so that NLog could be configured (via a custom LayoutRenderer) to output
the values stored in the CallContext?  Could the as-delivered
implementation of LogicalThreadProperties for NLog be NullContext but
someone could still develop a CallContext-based implementation (or based
on whatever technology they want) for their own use and substitute it in
- probably by implementing their own NLog logging adapter - or maybe by
subclassing the NLogLoggerFactoryAdapter and simply overriding the
"LogicalThreadProperties" property, providing their own implementation
for only that context.

I don't want to advocate for some overly complicated solution to the
logging context problem, but I do want to suggest that it might be
better to provide more (or at least the possibility of more if the end
user of Common.Logging wants to put in some work as well) capability
rather than less.

I am willing to send what I have done so far to the Common.Logging team
to see if it is worth including in Common.Logging (assuming you haven't
already implemented this functionality) in some form.  I am also willing
to discuss further if anyone is interested.

I hope this whole message makes it through rather than being too long
again.  I am sending as plain text, not html.

Willie Geoghegan.

Re: [Netcommon-developer] How I get the method name?

[Kenneth Xu <ke...@ho...>]

Willie is right, That is a bug in Common.Logging 2.0 when AbstractLogger was
introduced.

On Wed, Oct 13, 2010 at 1:57 PM, Geoghegan, William A (Willie) <
wil...@in...> wrote:

> If you have source code, try modifying Log4NetLogger.cs.  There is a
> line like this in the Fields region near the top of the file:
>
> private readonly static Type declaringType = typeof(Log4NetLogger);
>
> Try changing it to this:
>
> private readonly static Type declaringType = typeof(AbstractLogger);
>
> Note that I am using NLog right now, so I have not actually tried this
> with log4net.
>
> Willie.
>
> -----Original Message-----
> From: Seb...@gm... [mailto:Seb...@gm...]
> Sent: Thursday, September 16, 2010 8:46 AM
> To: net...@li...
> Subject: [Netcommon-developer] How I get the method name?
>
> Hi!
>
> I am using Common.Looging 2.0 and Log4Net with a RollingFileAppender.
> This works fine. Now I want to log the method name. So I adapted the
> ConversionPattern. This is my config now and it does not log the method
> names.
>
> <configSections>
>    <sectionGroup name="common">
>        <section name="logging"
> type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
>    </sectionGroup>
>
>    <section name="log4net"
> type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
> </configSections>
>
> <common>
>    <logging>
>        <factoryAdapter
> type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,
> Common.Logging.Log4net">
>            <arg key="configType" value="INLINE" />
>        </factoryAdapter>
>    </logging>
> </common>
>
> <log4net debug="false">
>
>    <appender name="RollingFileAppender"
> type="log4net.Appender.RollingFileAppender, log4net" >
>        <param name="File" value="logs\Test.log" />
>        <param name="AppendToFile" value="true" />
>        <param name="RollingStyle" value="Size" />
>        <param name="MaxSizeRollBackups" value="1" />
>        <param name="MaximumFileSize" value="10MB" />
>        <param name="StaticLogFileName" value="true" />
>
>        <layout type="log4net.Layout.PatternLayout, log4net">
>            <param name="ConversionPattern" value="%date{dd.MM.yyyy
> HH:mm:ss,fff} - %4thread - %-5level - %logger - %class.%method :
> %message%newline" />
>        </layout>
>
>    </appender>
>
>    <root>
>        <priority value="ALL" />
>
>        <appender-ref ref="RollingFileAppender" />
>    </root>
>
> </log4net>
>
>
> And this is the corresponding log, I miss the "Main()" method name.
>
> 16.09.2010 15:27:46,739 -   10 - DEBUG - ConsoleApplication1.Program -
> Common.Logging.Factory.AbstractLogger.Debug : testmessage
>
> What am I doing wrong?
> --
> Hi, ich bin SeboStone!
>
> Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
> Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
>
> ------------------------------------------------------------------------
> ------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>

Re: [Netcommon-developer] How I get the method name?

[Geoghegan, W. A (Willie) <wil...@in...>]

If you have source code, try modifying Log4NetLogger.cs.  There is a
line like this in the Fields region near the top of the file:

private readonly static Type declaringType = typeof(Log4NetLogger);

Try changing it to this:

private readonly static Type declaringType = typeof(AbstractLogger);

Note that I am using NLog right now, so I have not actually tried this
with log4net.

Willie.

-----Original Message-----
From: Seb...@gm... [mailto:Seb...@gm...] 
Sent: Thursday, September 16, 2010 8:46 AM
To: net...@li...
Subject: [Netcommon-developer] How I get the method name?

Hi!

I am using Common.Looging 2.0 and Log4Net with a RollingFileAppender.
This works fine. Now I want to log the method name. So I adapted the
ConversionPattern. This is my config now and it does not log the method
names.

<configSections>
    <sectionGroup name="common">
        <section name="logging"
type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
    </sectionGroup>

    <section name="log4net"
type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
</configSections>

<common>
    <logging>
        <factoryAdapter
type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter,
Common.Logging.Log4net">
            <arg key="configType" value="INLINE" />
        </factoryAdapter>
    </logging>
</common>

<log4net debug="false">

    <appender name="RollingFileAppender"
type="log4net.Appender.RollingFileAppender, log4net" >
        <param name="File" value="logs\Test.log" />
        <param name="AppendToFile" value="true" />
        <param name="RollingStyle" value="Size" />
        <param name="MaxSizeRollBackups" value="1" />
        <param name="MaximumFileSize" value="10MB" />
        <param name="StaticLogFileName" value="true" />

        <layout type="log4net.Layout.PatternLayout, log4net">
            <param name="ConversionPattern" value="%date{dd.MM.yyyy
HH:mm:ss,fff} - %4thread - %-5level - %logger - %class.%method :
%message%newline" />
        </layout>

    </appender>

    <root>
        <priority value="ALL" />

        <appender-ref ref="RollingFileAppender" />
    </root>

</log4net>


And this is the corresponding log, I miss the "Main()" method name.

16.09.2010 15:27:46,739 -   10 - DEBUG - ConsoleApplication1.Program -
Common.Logging.Factory.AbstractLogger.Debug : testmessage

What am I doing wrong?
-- 
Hi, ich bin SeboStone!

Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

------------------------------------------------------------------------
------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

Re: [Netcommon-developer] Is the project still alive?

[Mark P. <mpo...@vm...>]

Hi,

We do need help, just hasn't been enough time to find for this unfortunately.  Send a patch for some of the issues listed on SF (http://sourceforge.net/projects/netcommon/develop) if all looks cool, we would love to have you join the project!

Thanks,
Mark


> -----Original Message-----
> From: Matthias Gernand [mailto:mat...@gm...]
> Sent: Wednesday, October 13, 2010 12:24 PM
> To: net...@li...
> Subject: [Netcommon-developer] Is the project still alive?
> 
> Hi,
> 
> I am wondering if the project is still alive. The last checkin
> (rev 180) was 8 mounths ago. There are may new feature requests
> an possible bugs to resolve. So: will there be a new release in
> the near future? It would be sad if not, because Common.Logging
> is a great project! If you need any help developing let me know.
> I would like to participate and help with an new release.
> 
> Kind regards,
> Matthias
> 
> -----------------------------------------------------------------------
> -------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating
> great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer

[Netcommon-developer] Is the project still alive?

[Matthias G. <mat...@gm...>]

Hi,

I am wondering if the project is still alive. The last checkin
(rev 180) was 8 mounths ago. There are may new feature requests
an possible bugs to resolve. So: will there be a new release in
the near future? It would be sad if not, because Common.Logging
is a great project! If you need any help developing let me know.
I would like to participate and help with an new release.

Kind regards,
Matthias

Re: [Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

That’s ok with me.  My only complaint about the list is that it keeps rejecting my mails because they are too long.  Maybe I should try to be a bit less verbose ;-)

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: Monday, October 11, 2010 6:55 PM
To: Geoghegan, William A (Willie)
Cc: Erich Eichinger; net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

I'm too interested in this, so it would be nice if we can keep the conversation here instead of private. There aren't many subscriber on this list anyway.

Thanks,
Kenneth

On Mon, Oct 11, 2010 at 9:49 AM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Erich,

 

Thanks.  I understand about being busy.  Feel free to contact me directly or via the netcommon list if you have any questions about what I have posted.  I don’t know if there is any way that I can contribute, but I could certainly send you some work that I have done and you could decide for yourself if it looks useful or not.

 

Thanks again.

 

Willie.

 

From: Erich Eichinger [mailto:eei...@gm...] 
Sent: Monday, October 11, 2010 8:45 AM
To: 'Kenneth Xu'; Geoghegan, William A (Willie)


Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

Hi folks,

 

yes, I am. Unfortunately I am quite busy atm, I will come back to you as soon as possible, probably next week.

 

Thanks a lot Will for your effort, highly appreciated. Next week I hopefully have time to carefully read you posts and comment on them. Please be patient ;-)

 

cheers,

Erich

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: 11 October 2010 14:41
To: Geoghegan, William A (Willie); Erich Eichinger
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

William, I'm forwarding to Erich directly to see if he is still maintaining the project.

On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Too long again.  Part 1.

I have seen on the Common.Logging home page that Logging Context support is planned for the next release.  In the meantime, I have implemented a logging context abstraction that is based, in part, on Castle’s logging context abstraction that they provide for log4net and NLog.  At this point I consider it somewhat experimental, but I think there are some ok ideas here.  I also did not modify any Common.Logging code.  In a “real” implementation, I would expect that context would be available from LogManager (or maybe from ILog as was done in Castle).  I think that making it available from ILog could be misleading because it could be read as “the logging context for THIS logger”, which is not really true.

Anyway, with my code you can do something like to this to set the context (LogContext is my static object that provides the entry point into the logging context abstraction):

LogContext.GlobalProperties[“number”] = 1234;

LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push[“outer level”])

{

  DoSomeStuff();

  

  using (LogContext.ThreadStack.Push[“inner level”)

  {

    DoSomeStuffFromInnerLevel();

  }

}

Which logging context abstraction is in play is dictated by the current LogManager.Adapter’s implementation (or lack of same) of an interface, IContextProvider.  When one of the context operations (GlobalProperties, ThreadProperties, ThreadStack) is access on LogContext, code like this executes:

IContextProperties GlobalProperties

{

  get

  {

    IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;

    if (iacp == null)

    {

      return NullContextProvider.GlobalProperties; //Does nothing, but also does not fail.

    }

    else

    {

      return iacp.Context.GlobalProperties; //Global properties relevant to the currently abstracted logger

    }

  }

}

To take advantage of LogContext, I have copied the NLog abstraction provided by Common.Logging and added the IAdapterContextProvider interface.  Now, when I configure my NLog abstraction, LogContext finds that LogManager.Adapter does support the interface, so the NLog context values can be set.  I have done something similar for log4net.

William A. Geoghegan
Software Scientist
Intergraph Corporation
Security, Government & Infrastructure (SG&I) Division
P.O. Box 6695, Huntsville, AL 35824-0695 USA
P 1.256.730.8371
wil...@in..., www.intergraph.com 


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

 

 

Re: [Netcommon-developer] Common.Logging and logging contexts

[Kenneth Xu <ke...@ho...>]

I'm too interested in this, so it would be nice if we can keep the
conversation here instead of private. There aren't many subscriber on this
list anyway.

Thanks,
Kenneth

On Mon, Oct 11, 2010 at 9:49 AM, Geoghegan, William A (Willie) <
wil...@in...> wrote:

>  Erich,
>
>
>
> Thanks.  I understand about being busy.  Feel free to contact me directly
> or via the netcommon list if you have any questions about what I have
> posted.  I don’t know if there is any way that I can contribute, but I could
> certainly send you some work that I have done and you could decide for
> yourself if it looks useful or not.
>
>
>
> Thanks again.
>
>
>
> Willie.
>
>
>
> *From:* Erich Eichinger [mailto:eei...@gm...]
> *Sent:* Monday, October 11, 2010 8:45 AM
> *To:* 'Kenneth Xu'; Geoghegan, William A (Willie)
>
> *Cc:* net...@li...
> *Subject:* Re: [Netcommon-developer] Common.Logging and logging contexts
>
>
>
> Hi folks,
>
>
>
> yes, I am. Unfortunately I am quite busy atm, I will come back to you as
> soon as possible, probably next week.
>
>
>
> Thanks a lot Will for your effort, highly appreciated. Next week I
> hopefully have time to carefully read you posts and comment on them. Please
> be patient ;-)
>
>
>
> cheers,
>
> Erich
>
>
>
> *From:* ken...@gm... [mailto:ken...@gm...] *On Behalf Of *Kenneth
> Xu
> *Sent:* 11 October 2010 14:41
> *To:* Geoghegan, William A (Willie); Erich Eichinger
> *Cc:* net...@li...
> *Subject:* Re: [Netcommon-developer] Common.Logging and logging contexts
>
>
>
> William, I'm forwarding to Erich directly to see if he is still maintaining
> the project.
>
> On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <
> wil...@in...> wrote:
>
> Too long again.  Part 1.
>
> I have seen on the Common.Logging home page that Logging Context support is
> planned for the next release.  In the meantime, I have implemented a logging
> context abstraction that is based, in part, on Castle’s logging context
> abstraction that they provide for log4net and NLog.  At this point I
> consider it somewhat experimental, but I think there are some ok ideas
> here.  I also did not modify any Common.Logging code.  In a “real”
> implementation, I would expect that context would be available from
> LogManager (or maybe from ILog as was done in Castle).  I think that making
> it available from ILog could be misleading because it could be read as “the
> logging context for THIS logger”, which is not really true.
>
> Anyway, with my code you can do something like to this to set the context
> (LogContext is my static object that provides the entry point into the
> logging context abstraction):
>
> LogContext.GlobalProperties[“number”] = 1234;
>
> LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;
>
> using (LogContext.ThreadStack.Push[“outer level”])
>
> {
>
>   DoSomeStuff();
>
>
>
>   using (LogContext.ThreadStack.Push[“inner level”)
>
>   {
>
>     DoSomeStuffFromInnerLevel();
>
>   }
>
> }
>
> Which logging context abstraction is in play is dictated by the current
> LogManager.Adapter’s implementation (or lack of same) of an interface,
> IContextProvider.  When one of the context operations (GlobalProperties,
> ThreadProperties, ThreadStack) is access on LogContext, code like this
> executes:
>
> IContextProperties GlobalProperties
>
> {
>
>   get
>
>   {
>
>     IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;
>
>     if (iacp == null)
>
>     {
>
>       return NullContextProvider.GlobalProperties; //Does nothing, but also
> does not fail.
>
>     }
>
>     else
>
>     {
>
>       return iacp.Context.GlobalProperties; //Global properties relevant to
> the currently abstracted logger
>
>     }
>
>   }
>
> }
>
> To take advantage of LogContext, I have copied the NLog abstraction
> provided by Common.Logging and added the IAdapterContextProvider interface.
> Now, when I configure my NLog abstraction, LogContext finds that
> LogManager.Adapter does support the interface, so the NLog context values
> can be set.  I have done something similar for log4net.
>
> *William A. Geoghegan*
> Software Scientist
> Intergraph Corporation
> Security, Government & Infrastructure (SG&I) Division
> P.O. Box 6695, Huntsville, AL 35824-0695 USA
> *P* 1.256.730.8371
> *wil...@in...*, www.intergraph.com
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>
>

Re: [Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

Erich,

 

Thanks.  I understand about being busy.  Feel free to contact me directly or via the netcommon list if you have any questions about what I have posted.  I don’t know if there is any way that I can contribute, but I could certainly send you some work that I have done and you could decide for yourself if it looks useful or not.

 

Thanks again.

 

Willie.

 

From: Erich Eichinger [mailto:eei...@gm...] 
Sent: Monday, October 11, 2010 8:45 AM
To: 'Kenneth Xu'; Geoghegan, William A (Willie)
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

Hi folks,

 

yes, I am. Unfortunately I am quite busy atm, I will come back to you as soon as possible, probably next week.

 

Thanks a lot Will for your effort, highly appreciated. Next week I hopefully have time to carefully read you posts and comment on them. Please be patient ;-)

 

cheers,

Erich

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: 11 October 2010 14:41
To: Geoghegan, William A (Willie); Erich Eichinger
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

William, I'm forwarding to Erich directly to see if he is still maintaining the project.

On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Too long again.  Part 1.

I have seen on the Common.Logging home page that Logging Context support is planned for the next release.  In the meantime, I have implemented a logging context abstraction that is based, in part, on Castle’s logging context abstraction that they provide for log4net and NLog.  At this point I consider it somewhat experimental, but I think there are some ok ideas here.  I also did not modify any Common.Logging code.  In a “real” implementation, I would expect that context would be available from LogManager (or maybe from ILog as was done in Castle).  I think that making it available from ILog could be misleading because it could be read as “the logging context for THIS logger”, which is not really true.

Anyway, with my code you can do something like to this to set the context (LogContext is my static object that provides the entry point into the logging context abstraction):

LogContext.GlobalProperties[“number”] = 1234;

LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push[“outer level”])

{

  DoSomeStuff();

  

  using (LogContext.ThreadStack.Push[“inner level”)

  {

    DoSomeStuffFromInnerLevel();

  }

}

Which logging context abstraction is in play is dictated by the current LogManager.Adapter’s implementation (or lack of same) of an interface, IContextProvider.  When one of the context operations (GlobalProperties, ThreadProperties, ThreadStack) is access on LogContext, code like this executes:

IContextProperties GlobalProperties

{

  get

  {

    IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;

    if (iacp == null)

    {

      return NullContextProvider.GlobalProperties; //Does nothing, but also does not fail.

    }

    else

    {

      return iacp.Context.GlobalProperties; //Global properties relevant to the currently abstracted logger

    }

  }

}

To take advantage of LogContext, I have copied the NLog abstraction provided by Common.Logging and added the IAdapterContextProvider interface.  Now, when I configure my NLog abstraction, LogContext finds that LogManager.Adapter does support the interface, so the NLog context values can be set.  I have done something similar for log4net.

William A. Geoghegan
Software Scientist
Intergraph Corporation
Security, Government & Infrastructure (SG&I) Division
P.O. Box 6695, Huntsville, AL 35824-0695 USA
P 1.256.730.8371
wil...@in..., www.intergraph.com 


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

 

Re: [Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

Thanks, I appreciate it.

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: Monday, October 11, 2010 8:41 AM
To: Geoghegan, William A (Willie); Erich Eichinger
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

William, I'm forwarding to Erich directly to see if he is still maintaining the project.

On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Too long again.  Part 1.

I have seen on the Common.Logging home page that Logging Context support is planned for the next release.  In the meantime, I have implemented a logging context abstraction that is based, in part, on Castle’s logging context abstraction that they provide for log4net and NLog.  At this point I consider it somewhat experimental, but I think there are some ok ideas here.  I also did not modify any Common.Logging code.  In a “real” implementation, I would expect that context would be available from LogManager (or maybe from ILog as was done in Castle).  I think that making it available from ILog could be misleading because it could be read as “the logging context for THIS logger”, which is not really true.

Anyway, with my code you can do something like to this to set the context (LogContext is my static object that provides the entry point into the logging context abstraction):

LogContext.GlobalProperties[“number”] = 1234;

LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push[“outer level”])

{

  DoSomeStuff();

  

  using (LogContext.ThreadStack.Push[“inner level”)

  {

    DoSomeStuffFromInnerLevel();

  }

}

Which logging context abstraction is in play is dictated by the current LogManager.Adapter’s implementation (or lack of same) of an interface, IContextProvider.  When one of the context operations (GlobalProperties, ThreadProperties, ThreadStack) is access on LogContext, code like this executes:

IContextProperties GlobalProperties

{

  get

  {

    IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;

    if (iacp == null)

    {

      return NullContextProvider.GlobalProperties; //Does nothing, but also does not fail.

    }

    else

    {

      return iacp.Context.GlobalProperties; //Global properties relevant to the currently abstracted logger

    }

  }

}

To take advantage of LogContext, I have copied the NLog abstraction provided by Common.Logging and added the IAdapterContextProvider interface.  Now, when I configure my NLog abstraction, LogContext finds that LogManager.Adapter does support the interface, so the NLog context values can be set.  I have done something similar for log4net.

William A. Geoghegan
Software Scientist
Intergraph Corporation
Security, Government & Infrastructure (SG&I) Division
P.O. Box 6695, Huntsville, AL 35824-0695 USA
P 1.256.730.8371
wil...@in..., www.intergraph.com 


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

 

Re: [Netcommon-developer] Common.Logging and logging contexts

[Erich E. <eei...@gm...>]

Hi folks,

 

yes, I am. Unfortunately I am quite busy atm, I will come back to you as soon as possible, probably next week.

 

Thanks a lot Will for your effort, highly appreciated. Next week I hopefully have time to carefully read you posts and comment on them. Please be patient ;-)

 

cheers,

Erich

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: 11 October 2010 14:41
To: Geoghegan, William A (Willie); Erich Eichinger
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

William, I'm forwarding to Erich directly to see if he is still maintaining the project.

On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Too long again.  Part 1.

I have seen on the Common.Logging home page that Logging Context support is planned for the next release.  In the meantime, I have implemented a logging context abstraction that is based, in part, on Castle’s logging context abstraction that they provide for log4net and NLog.  At this point I consider it somewhat experimental, but I think there are some ok ideas here.  I also did not modify any Common.Logging code.  In a “real” implementation, I would expect that context would be available from LogManager (or maybe from ILog as was done in Castle).  I think that making it available from ILog could be misleading because it could be read as “the logging context for THIS logger”, which is not really true.

Anyway, with my code you can do something like to this to set the context (LogContext is my static object that provides the entry point into the logging context abstraction):

LogContext.GlobalProperties[“number”] = 1234;

LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push[“outer level”])

{

  DoSomeStuff();

  

  using (LogContext.ThreadStack.Push[“inner level”)

  {

    DoSomeStuffFromInnerLevel();

  }

}

Which logging context abstraction is in play is dictated by the current LogManager.Adapter’s implementation (or lack of same) of an interface, IContextProvider.  When one of the context operations (GlobalProperties, ThreadProperties, ThreadStack) is access on LogContext, code like this executes:

IContextProperties GlobalProperties

{

  get

  {

    IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;

    if (iacp == null)

    {

      return NullContextProvider.GlobalProperties; //Does nothing, but also does not fail.

    }

    else

    {

      return iacp.Context.GlobalProperties; //Global properties relevant to the currently abstracted logger

    }

  }

}

To take advantage of LogContext, I have copied the NLog abstraction provided by Common.Logging and added the IAdapterContextProvider interface.  Now, when I configure my NLog abstraction, LogContext finds that LogManager.Adapter does support the interface, so the NLog context values can be set.  I have done something similar for log4net.

William A. Geoghegan
Software Scientist
Intergraph Corporation
Security, Government & Infrastructure (SG&I) Division
P.O. Box 6695, Huntsville, AL 35824-0695 USA
P 1.256.730.8371
wil...@in..., www.intergraph.com 


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

 

Re: [Netcommon-developer] Common.Logging and logging contexts

[Kenneth Xu <ke...@ho...>]

William, I'm forwarding to Erich directly to see if he is still maintaining
the project.

On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <
wil...@in...> wrote:

>  Too long again.  Part 1.
>
> I have seen on the Common.Logging home page that Logging Context support is
> planned for the next release.  In the meantime, I have implemented a logging
> context abstraction that is based, in part, on Castle’s logging context
> abstraction that they provide for log4net and NLog.  At this point I
> consider it somewhat experimental, but I think there are some ok ideas
> here.  I also did not modify any Common.Logging code.  In a “real”
> implementation, I would expect that context would be available from
> LogManager (or maybe from ILog as was done in Castle).  I think that making
> it available from ILog could be misleading because it could be read as “the
> logging context for THIS logger”, which is not really true.
>
> Anyway, with my code you can do something like to this to set the context
> (LogContext is my static object that provides the entry point into the
> logging context abstraction):
>
> LogContext.GlobalProperties[“number”] = 1234;
>
> LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;
>
> using (LogContext.ThreadStack.Push[“outer level”])
>
> {
>
>   DoSomeStuff();
>
>
>
>   using (LogContext.ThreadStack.Push[“inner level”)
>
>   {
>
>     DoSomeStuffFromInnerLevel();
>
>   }
>
> }
>
> Which logging context abstraction is in play is dictated by the current
> LogManager.Adapter’s implementation (or lack of same) of an interface,
> IContextProvider.  When one of the context operations (GlobalProperties,
> ThreadProperties, ThreadStack) is access on LogContext, code like this
> executes:
>
> IContextProperties GlobalProperties
>
> {
>
>   get
>
>   {
>
>     IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;
>
>     if (iacp == null)
>
>     {
>
>       return NullContextProvider.GlobalProperties; //Does nothing, but also
> does not fail.
>
>     }
>
>     else
>
>     {
>
>       return iacp.Context.GlobalProperties; //Global properties relevant to
> the currently abstracted logger
>
>     }
>
>   }
>
> }
>
> To take advantage of LogContext, I have copied the NLog abstraction
> provided by Common.Logging and added the IAdapterContextProvider interface.
> Now, when I configure my NLog abstraction, LogContext finds that
> LogManager.Adapter does support the interface, so the NLog context values
> can be set.  I have done something similar for log4net.
>
> *******William A. Geoghegan*
> Software Scientist
> Intergraph Corporation
> Security, Government & Infrastructure (SG&I) Division
> P.O. Box 6695, Huntsville, AL 35824-0695 USA
> *******P* 1.256.730.8371
> *****wil...@in...*, www.intergraph.com
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>

[Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

Too long again.  Part 1.

I have seen on the Common.Logging home page that Logging Context support
is planned for the next release.  In the meantime, I have implemented a
logging context abstraction that is based, in part, on Castle's logging
context abstraction that they provide for log4net and NLog.  At this
point I consider it somewhat experimental, but I think there are some ok
ideas here.  I also did not modify any Common.Logging code.  In a "real"
implementation, I would expect that context would be available from
LogManager (or maybe from ILog as was done in Castle).  I think that
making it available from ILog could be misleading because it could be
read as "the logging context for THIS logger", which is not really true.

Anyway, with my code you can do something like to this to set the
context (LogContext is my static object that provides the entry point
into the logging context abstraction):

LogContext.GlobalProperties["number"] = 1234;
LogContext.ThreadProperties["id"] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push["outer level"])
{
  DoSomeStuff();
  
  using (LogContext.ThreadStack.Push["inner level")
  {
    DoSomeStuffFromInnerLevel();
  }
}

Which logging context abstraction is in play is dictated by the current
LogManager.Adapter's implementation (or lack of same) of an interface,
IContextProvider.  When one of the context operations (GlobalProperties,
ThreadProperties, ThreadStack) is access on LogContext, code like this
executes:

IContextProperties GlobalProperties
{
  get
  {
    IAdapterContextProvider iacp = LogManager.Adapter as
IContextProvider;
    if (iacp == null)
    {
      return NullContextProvider.GlobalProperties; //Does nothing, but
also does not fail.
    }
    else
    {
      return iacp.Context.GlobalProperties; //Global properties relevant
to the currently abstracted logger
    }
  }
}

To take advantage of LogContext, I have copied the NLog abstraction
provided by Common.Logging and added the IAdapterContextProvider
interface.  Now, when I configure my NLog abstraction, LogContext finds
that LogManager.Adapter does support the interface, so the NLog context
values can be set.  I have done something similar for log4net.



William A. Geoghegan 
Software Scientist 
Intergraph Corporation 
Security, Government & Infrastructure (SG&I) Division 
P.O. Box 6695, Huntsville, AL 35824-0695 USA 
P 1.256.730.8371 
wil...@in..., www.intergraph.com 

[Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

Part 2.

I also implemented a thread stack (NDC) for
Trace.CorrelationManager.LogicalOperationStack.  

I also provided an implementation of GlobalProperties, ThreadProperties,
and ThreadStack (taken largely from NLog).  They could be used in a
context where there is not a "real" logging platform behind the
Common.Logging abstraction.  Say you have a logger for Silverlight that
logs to the debugger and might log to a WCF LogService.  Context can
still be captured.  The logging implementation, such as it is, can get
the context information and do something with it.  Don't know how useful
it will prove to.

This could easily occur inside of LogManager so a user of Common.Logging
could write something like this:

LogManager.GlobalProperties["name"] = "hello"; //set the "name" global
property on currently abstracted logging platform.

Some notable items:
1.	 Log4net provides properties and stack info for both "thread"
and "logical thread".  From what I can tell, the "thread" values
(formerly MDC and NDC) are way more commonly used then the "logical
thread" values.  Castle did not implement an abstraction for the
"logical" flavor.
2.	Log4net provides for multiple stacks per thread.  Castle exposes
this.
3.	NLog does not provide a "logical thread" context, even in NLog
2.0.  Castle's implementation exposes "ThreadStacks" (presumably to
support log4net's multiple stacks) but the implementation always hands
back the one NLog stack (NDC/NestedDiagnosticContext) for the thread,
regardless of what stack was requested.
4.	Log4net allows objects to be set in the "properties" collections
and strings to be pushed onto the stacks.  NLog only allows strings as
"properties" and entries on the stack.  Castle exposes a string for both
the "properties" and the stack.
5.	Castle based their "properties" implementation on log4net's
"BaseProperties" (maybe not right name), which has only a get/set
property bag interface.  As such, they did not implement Clear or
Remove.  It seems to make more sense to have Clear and Remove.

If the most common usage of the thread stacks is to have one stack
(NDC), and since NLog has only one stack anyway, I wonder if it really
makes sense to expose the stacks/stack such that you have to write code
like this:

LogContext.ThreadStacks["NDC"].Push("whatever");

Maybe it is better to either only expose one stack or expose a stack AND
a dictionary of stacks.  Normally one might just use the single (or
default) stack.  If there is a particular application or workflow that
wants to use multiple stacks, they would be there.

LogContext.ThreadStack.Push("whatever"); //pushes onto NDC
LogContext.ThreadStacks["custom stack"].Push("whatever"); //pushes onto
custom stack.

If anyone at Common.Logging is interested in discussing this and whether
or it is relevant or not to Common.Logging's implementation (when?) of
logging contexts, please respond.  Also, if anyone at Common.Logging
would like to see what I have done and how it might or might not fit
into Common.Logging, also please respond.

Thanks.

Willie Geoghegan.

[Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

I have seen on the Common.Logging home page that Logging Context support
is planned for the next release.  In the meantime, I have implemented a
logging context abstraction that is based, in part, on Castle's logging
context abstraction that they provide for log4net and NLog.  At this
point I consider it somewhat experimental, but I think there are some ok
ideas here.  I also did not modify any Common.Logging code.  In a "real"
implementation, I would expect that context would be available from
LogManager (or maybe from ILog as was done in Castle).  I think that
making it available from ILog could be misleading because it could be
read as "the logging context for THIS logger", which is not really true.

Anyway, with my code you can do something like to this to set the
context (LogContext is my static object that provides the entry point
into the logging context abstraction):

LogContext.GlobalProperties["number"] = 1234;
LogContext.ThreadProperties["id"] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push["outer level"])
{
  DoSomeStuff();
  
  using (LogContext.ThreadStack.Push["inner level")
  {
    DoSomeStuffFromInnerLevel();
  }
}

Which logging context abstraction is in play is dictated by the current
LogManager.Adapter's implementation (or lack of same) of an interface,
IContextProvider.  When one of the context operations (GlobalProperties,
ThreadProperties, ThreadStack) is access on LogContext, code like this
executes:

IContextProperties GlobalProperties
{
  get
  {
    IAdapterContextProvider iacp = LogManager.Adapter as
IContextProvider;
    if (iacp == null)
    {
      return NullContextProvider.GlobalProperties; //Does nothing, but
also does not fail.
    }
    else
    {
      return iacp.Context.GlobalProperties; //Global properties relevant
to the currently abstracted logger
    }
  }
}

To take advantage of LogContext, I have copied the NLog abstraction
provided by Common.Logging and added the IAdapterContextProvider
interface.  Now, when I configure my NLog abstraction, LogContext finds
that LogManager.Adapter does support the interface, so the NLog context
values can be set.  I have done something similar for log4net.

I also implemented a thread stack (NDC) for
Trace.CorrelationManager.LogicalOperationStack.  

I also provided an implementation of GlobalProperties, ThreadProperties,
and ThreadStack (taken largely from NLog).  They could be used in a
context where there is not a "real" logging platform behind the
Common.Logging abstraction.  Say you have a logger for Silverlight that
logs to the debugger and might log to a WCF LogService.  Context can
still be captured.  The logging implementation, such as it is, can get
the context information and do something with it.  Don't know how useful
it will prove to.

This could easily occur inside of LogManager so a user of Common.Logging
could write something like this:

LogManager.GlobalProperties["name"] = "hello"; //set the "name" global
property on currently abstracted logging platform.

Some notable items:
1.	 Log4net provides properties and stack info for both "thread"
and "logical thread".  From what I can tell, the "thread" values
(formerly MDC and NDC) are way more commonly used then the "logical
thread" values.  Castle did not implement an abstraction for the
"logical" flavor.
2.	Log4net provides for multiple stacks per thread.  Castle exposes
this.
3.	NLog does not provide a "logical thread" context, even in NLog
2.0.  Castle's implementation exposes "ThreadStacks" (presumably to
support log4net's multiple stacks) but the implementation always hands
back the one NLog stack (NDC/NestedDiagnosticContext) for the thread,
regardless of what stack was requested.
4.	Log4net allows objects to be set in the "properties" collections
and strings to be pushed onto the stacks.  NLog only allows strings as
"properties" and entries on the stack.  Castle exposes a string for both
the "properties" and the stack.
5.	Castle based their "properties" implementation on log4net's
"BaseProperties" (maybe not right name), which has only a get/set
property bag interface.  As such, they did not implement Clear or
Remove.  It seems to make more sense to have Clear and Remove.

If the most common usage of the thread stacks is to have one stack
(NDC), and since NLog has only one stack anyway, I wonder if it really
makes sense to expose the stacks/stack such that you have to write code
like this:

LogContext.ThreadStacks["NDC"].Push("whatever");

Maybe it is better to either only expose one stack or expose a stack AND
a dictionary of stacks.  Normally one might just use the single (or
default) stack.  If there is a particular application or workflow that
wants to use multiple stacks, they would be there.

LogContext.ThreadStack.Push("whatever"); //pushes onto NDC
LogContext.ThreadStacks["custom stack"].Push("whatever"); //pushes onto
custom stack.

If anyone at Common.Logging is interested in discussing this and whether
or it is relevant or not to Common.Logging's implementation (when?) of
logging contexts, please respond.  Also, if anyone at Common.Logging
would like to see what I have done and how it might or might not fit
into Common.Logging, also please respond.

Thanks.

Willie Geoghegan.

Re: [Netcommon-developer] Runtime error with custom LoggerFactoryAdapter/Logger

[Geoghegan, W. A (Willie) <wil...@in...>]

Thanks, that fixed it.  I had not used that particular syntax ( :this( … ) ) before and I did not follow your suggestion correctly.

 

I ended up with something like this:

 

MyAdapter : AbstractCachingLoggerFactoryAdapter

{

  public MyAdapter(NameValueCollection properties)

  {

    //No code here because I don’t need any config params right now

  }

 

  public MyAdapter()

    : this(new NameValueCollection())

  {

    //Parameterless constructor so I don’t have to put a dummy param in the app.config file

  }

}

 

Thanks again.

 

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: Friday, September 24, 2010 10:16 AM
To: Geoghegan, William A (Willie)
Subject: Re: [Netcommon-developer] Runtime error with custom LoggerFactoryAdapter/Logger

 

This is because you didn't derive the the correct constructor. That's way I ask you to use ': this( new NameValueCollection()){}' in my previous email.

On Fri, Sep 24, 2010 at 11:12 AM, Geoghegan, William A (Willie) <wil...@in...> wrote:

If I try to add a parameterless constructor, it won’t compile because Common.Logging.Factory.AbstractCachingLoggerFactoryAdapter (from which I derived my adapter) does not contain a constructor that takes 0 arguments.

 

Re: [Netcommon-developer] Runtime error with custom LoggerFactoryAdapter/Logger

[Geoghegan, W. A (Willie) <wil...@in...>]

No, I haven’t.  Thanks for the suggestion.

 

If I try to add a parameterless constructor, it won’t compile because Common.Logging.Factory.AbstractCachingLoggerFactoryAdapter (from which I derived my adapter) does not contain a constructor that takes 0 arguments.

 

It seems like maybe the AbstractCachingLoggingFactoryAdapter should have a parameterless constructor so that it is possible to create an AbstractCachingLoggingFactoryAdapter-derived adapter that takes no configuration parameters.  As it stands now, it seems that you cannot be derived from AbstractCachingLoggingFactoryAdapter AND have no configuration parameters.

 

 

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: Friday, September 24, 2010 9:18 AM
To: Geoghegan, William A (Willie)
Cc: net...@li...
Subject: Re: [Netcommon-developer] Runtime error with custom LoggerFactoryAdapter/Logger

 

Have you try to add a parameterless constructor this way?

YourFactory() : this( new NameValueCollection()){}

On Mon, Sep 13, 2010 at 12:37 PM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Hello,

I am currently evaluating Common.Logging.  I have implemented a custom LoggerFactoryAdapter/Logger to wrap a logger that I wrote that logs via System.Diagnostics.TraceSource.  Because the underlying logger is based on TraceSources, my factory does not require any additional configuration parameters.  I created my logger factory adapter by subclassing from AbstractCachingLoggerFactoryAdapter and implementing the constructor which takes the NameValueCollection and also the CreateLogger method.

When I configure Common.Logging (via the app.config file) to use my custom logger factory adapter, I get an exception that says:

“Unable to create instance of type <my fully qualified logger factory adapter class>.  Possible explanation is lack of zero arg and single arg NameValueCollection constructors.”

The inner exception says “No parameterless constructor defined for this object”.

I do have the NameValueCollection constructor, however, I do not have any configuration parameters in my app.config file (since my factory does not require any).  I tried adding a zero arg constructor and got a compile error that the AbstractCachingLoggerFactoryAdapter does not contain a constructor that takes 0 arguments.

I have worked around this by simply adding a dummy name/value pair to my factory adapter’s configuration.  It seems like it should be ok to have no configuration properties and that Common.Logging should be tolerant.  

Inside of LogManager.cs in BuildLoggerFactoryAdapterFromLogSettings around line 303, setting.Properties is tested.  If it is not null and if setting.Properties.Count > 0, then the adapter is created via the “NameValueCollection” constructor.  Otherwise, it is created via the zero arg constructor.

Thanks.

Willie Geoghegan.


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer

 

Re: [Netcommon-developer] Runtime error with custom LoggerFactoryAdapter/Logger

[Kenneth Xu <ke...@ho...>]

Have you try to add a parameterless constructor this way?

YourFactory() : this( new NameValueCollection()){}

On Mon, Sep 13, 2010 at 12:37 PM, Geoghegan, William A (Willie) <
wil...@in...> wrote:

>  Hello,
>
> I am currently evaluating Common.Logging.  I have implemented a custom LoggerFactoryAdapter/Logger
> to wrap a logger that I wrote that logs via System.Diagnostics.TraceSource.  Because
> the underlying logger is based on TraceSources, my factory does not
> require any additional configuration parameters.  I created my logger
> factory adapter by subclassing from AbstractCachingLoggerFactoryAdapter
> and implementing the constructor which takes the NameValueCollection and
> also the CreateLogger method.
>
> When I configure Common.Logging (via the app.config file) to use my custom
> logger factory adapter, I get an exception that says:
>
> “Unable to create instance of type <my fully qualified logger factory
> adapter class>.  Possible explanation is lack of zero arg and single arg
> NameValueCollection constructors.”
>
> The inner exception says “No parameterless constructor defined for this
> object”.
>
> I do have the NameValueCollection constructor, however, I do not have any
> configuration parameters in my app.config file (since my factory does not
> require any).  I tried adding a zero arg constructor and got a compile error
> that the AbstractCachingLoggerFactoryAdapter does not contain a
> constructor that takes 0 arguments.
>
> I have worked around this by simply adding a dummy name/value pair to my
> factory adapter’s configuration.  It seems like it should be ok to have no
> configuration properties and that Common.Logging should be tolerant.
>
> Inside of LogManager.cs in BuildLoggerFactoryAdapterFromLogSettings around
> line 303, setting.Properties is tested.  If it is not null and if
> setting.Properties.Count > 0, then the adapter is created via the “
> NameValueCollection” constructor.  Otherwise, it is created via the zero
> arg constructor.
>
> Thanks.
>
> Willie Geoghegan.
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
>
> _______________________________________________
> Netcommon-developer mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netcommon-developer
>
>

[Netcommon-developer] Context support in next version

[Geoghegan, W. A (Willie) <wil...@in...>]

Part 2
Finally, FWIW, I think the Castle approach of having the logging context
interfaces available from their logger interface is reasonable, given
that users of Castle probably only have access to a logger interface
(probably no LogManager).

Given that Common.Logging exposes LogManager, it seems reasonable that
the logging context properties might be available through LogManager
(and provided, ultimately, by the implementation of
ILoggerFactoryAdapter).  It seems like it would be ok to expose the
properties via the ILog interface as well, but probably not necessary if
already exposed via LogManager.  Any logging system that is exposed
through Common.Logging (either implemented by Common.Logging or by
someone else and plugged into Common.Logging) should expose at least a
"do nothing" implemention (like NullLogger) so that code that requests
to set/get a logging context gets an actual object rather than a null.
LogManager could expose something like this:

IContextProperties GlobalContextProperties
{
  get
  {
    IContextProperties prop = _adapter.GlobalContextProperties;
    if (prop == null)
    {
      return new NullContextProperties();  //Maybe cache this or have a
single static version
    }
    else
    {
      return prop;
    }
  }
}

Similarly for ThreadContextProperties and ThreadContextStack.

The AbstractSimpleFactoryAdapter or AbstractCachingFactoryAdapter can
provide default implementations of these properties.  The default
implementation just returns an implementation of the interface that does
not actually allow for setting/getting properties.  This solves the
problem of getting a null object if an adapter does not support these
properties.  Log4net and NLog factory adapters would return
implementations of the interfaces that actually delegate down to the
corresponding log4net or NLog context properties (a la Castle).  If
someone wanted to write a TraceSource-based abstraction, they could
provide an implementation of the ThreadContextStack that delegates to
Trace.CorrelationManager.StartLogicalOperation/StopLogicalOperation
(maybe that would work, maybe not), but might choose to not implement
either of the context properties interfaces since System.Diagnostics
does not necessarily have functionality that corresponds directly.

By providing default (if dumb) implementations of these properties in
AbstractSimpleFactoryAdapter and/or AbstractCachingFactoryAdapter,
Common.Logging allows existing Common.Logging plugins to still work
without any code modification.

Finally, regarding Silverlight support ...  Will the Common.Logging
codebase be modified such that LogManager can be created and used within
a Silverlight app?  Will I able to add a reference to Common.Logging (or
maybe to something like Common.Logging.Silverlight) to a Silverlight
project, configure it (programmatically), and then log?  Something like
this:

LogManager.Adapter = new
SilverlightDebuggerLoggerFactoryAdapter(LogLevel.Info);
ILog logger = LogManager.GetCurrentClassLogger();
logger.Info("Hello from Silverlight!");

Or like this:

//LoggingService could be a WCF service implemented by me, along with
corresponding adapter and logger
LogManager.Adapter = new
LoggingServiceLoggerFactoryAdapter(LogLevel.Info, <parameters to connect
to LoggingService>);
ILog logger = LogManager.GetCurrentClassLogger();
logger.Info("Hello from Silverlight via LoggingService!");

If possible, could someone from Common.Logging respond to this email
with some information as to how and when you expect to support logging
contexts and Silverlight?  I don't think that it is critical for our
project that we have logging context support NOW, but it would be useful
to have some timeframe and some idea of your approach so that, if we
need it and it won't be available in our timeframe, that we could
implement something that would at least be close to the expected
Common.Logging implementation.  We will be doing a lot of Silverlight,
so Silverlight support will be important.

Note that I added an issue to the tracker regarding adding a "Log"
method (maybe overloaded, maybe not) to the ILog interface.  The method
should be similar to the Log method provided by log4net and NLog in that
it would accept a "LogEvent" structure, similar to LogEventInfo or
LoggingEvent.  The usage that I had in mind for this would be the
implementation of a LoggingService (WCF or other similar service) that
would accept fully formed logging events from some remote client or
service.  So, a client-based logger (say a
LoggingServiceLoggerFactoryAdapter/LoggingServiceLogger) would construct
LogEvent classes/structures in the WriteInternal method:

protected override void WriteInternal(LogLevel level, object message,
Exception ex)
{
  //Create a LoggingServiceEvent to send to the LoggingService
  LoggingServiceEvent lse = new LoggingServiceEvent(DateTime.Now, level,
LoggerName(), message, ex, <maybe some context info in a dictionary>);
  _loggingService.SendLogMessage(lse); //Send via WCF to LoggingService
}

(Note that in order to create a "LoggingServiceEvent" the Name of the
logger instance is probably useful, if no required.  Therefore, could
Name be available either from ILog interface or could the logger name be
made available for logger implementers via the AbstractLogger and/or
AbstractSimpleLogger.)

Inside of a LoggingService (that is implemented in terms of
Common.Logging):

public void SendLogMessage(LoggingServiceEvent lse)
{
  //Take LoggingServiceEvent, convert to Common.Logging.LogEvent, log
via Common.Logging.ILog
  ILog logger = LogManager.GetLogger(le.LoggerName);
  LogEvent le = ConvertLoggingServiceEventToCommonLoggingLogEvent(lse);
  logger.Log(le);
}

Thanks.

Looking forward to a response.

Willie Geoghegan.

[Netcommon-developer] Context support in next version

[Geoghegan, W. A (Willie) <wil...@in...>]

Msg was too long.  Posting in two parts.
Part 1.

Hello,

On the Common.Logging website, the "Release Schedule" note near the
bottom lists some features planned for the next release.  These features
include:
Partial Trust compliance (already in trunk)
Support for Windows Azure
Support for Silverlight
Logging Context support (in progress)

It also says the next release is scheduled to be in "June".  I asked in
an earlier message about what the expected timeframe is for the release,
so I won't ask again here.

I do want to ask about the Logging Context support and Silverlight
support (Silverlight towards the end of this mail).

I think that logging context will be a useful addition.  I have some
questions about how you are planning to implement it:
1.	Do you plan to expose context information via the ILog interface
(similar to the Castle approach - see their git repository)?
2.	Do you plan to expose context information via the LogManager?
3.	Do you plan to provide a default implementation for abstractions
that don't natively support logging context, at least a "NullContext"
context provider that provides an object (rather than null) that does
not actually do anything.
4.	What will the exposed interface/programming model look like?

Castle has implemented an abstraction of Logging Context, at least for
their log4net and NLog logging implementations.  It appears, from
looking at their git repository, that they have defined some interfaces:
IGlobalContextProperties, IThreadContextProperties,
IThreadContextStacks, and IThreadContextStack.  It is easy enough to
look in the Castle git repository at how these interfaces were
implemented for log4net and NLog to see exactly how the interfaces
relate to the various logging contexts.  The interfaces themselves are
exposed from the loggers.  So, if you have a Castle NLog logger you
could get/set a GlobalContextProperties value something like this:

ILogger logger = <I guess in Castle the logger is probably injected
rather than retrieved via a LogManager>;
Logger.GlobalContextProperties["MyProperty"] = 12345;

That's pretty good.  Anywhere you have access to a logger (ILogger
implementation), you can get/set any of the logging context
properties/stacks.

On the other hand, it seems that you HAVE to have a logger to do this
(in the absence of a LogManager).

One other shortcoming (at least to me) in Castle's implementation is
that it looks like the logging context interfaces are only implemented
on the "IExtendedLogger" interface, which I think is only implemented on
the log4net and NLog abstractions.  If you (as a user of Castle) should
choose to inject IExtendedLogger, you are in good shape.  You can have
access to context info.  If you inject ILogger, you don't have access to
context info.  If the only abstractions that implement IExtendedLogger
are the log4net and NLog abstractions, then you can only use those
abstractions if you inject IExtendedLogger.  Maybe you want to use one
of their other built-in abstractions (like Console) or the one that is
based on TraceSources (which, BTW, provides some hierarchical logger
capability).  However, since none of these logging abstractions support
IExtendedLogger (only log4net and NLog abstractions support it), you
cannot use any of them (without changing your app code to depend on
ILogger rather than IExtendedLogger).  Anyway, that may or may not be
that important.

So, if at the beginning of your program you want to set some global
properties (like product version, app start time, whatever), you
probably cannot set them without first getting (or having injected) a
logger.  Maybe this is not a big deal, maybe it is.

With log4net you could do something like this:

log4net.GlobalContextProperties["Version"] = GetProductVersion();
log4net.GlobalContextProperties["StartTime"] = DateTime.Now;

With Castle, assuming you have a logger handy, you could do something
like this:

logger.GlobalContextProperties["Version"] = GetProductVersion();
logger.GlobalContextProperties["StartTime"] = DateTime.Now();

It seems useful to me to be able to set the various context properties
without first getting a logger.  Maybe something like this:

LogManager.GlobalContextProperties["Version"] = GetProductVersion();
LogManager.GlobalContextProperties["StartTime"] = DateTime.Now();


Since the LogManager.Adapter IS the implementation of the logging
abstraction over a specific logging framework, the Common.Logging
LogManager could delegate to the ILoggerFactoryAdapter to do the work.
This is nice because the LogManager is always available so it would be
easy for anyone to set logging context information at any time.  

On the other hand, does this make it awkward for people that want to
implement Adapters and Loggers but might not have the concept of logging
context?  What if someone wants to make a logging abstraction over
System.Diagnostics (using TraceSources)?  System.Diagnostics has the
Trace.CorrelationManager.LogicalOperationStack that seems to correspond
pretty well to ThreadContextStack, but it does not have things that
correspond very well to GlobalContextProperties or
ThreadContextProperties (at least not explicitly exposed as such from
Trace).  Does it matter?  If someone writes a logging abstraction that
can be plugged into Common.Logging and the logging system that they are
abstracting does not have context information, they could just not
implement any or all of the context interfaces.  

The default implementation (provided by Common.Logging) could just
return a "do nothing" implementation (like NullLogger), so that any code
written against Common.Logging interfaces does not have to worry that
"GlobalContextProperties" might be null.  Alternatively (and obviously
more work), Common.Logging could provide an implementation of each type
of context (global properties, thread local properties, thread local
stack).  Might be nice, but probably overkill unless there is a demand
for it.  It seems like it wouldn't be that hard to implement if someone
really wanted to do it.

[Netcommon-developer] How I get the method name?

[<Seb...@gm...>]

Hi!

I am using Common.Looging 2.0 and Log4Net with a RollingFileAppender. This works fine. Now I want to log the method name. So I adapted the ConversionPattern. This is my config now and it does not log the method names.

<configSections>
    <sectionGroup name="common">
        <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
    </sectionGroup>

    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
</configSections>

<common>
    <logging>
        <factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4net">
            <arg key="configType" value="INLINE" />
        </factoryAdapter>
    </logging>
</common>

<log4net debug="false">

    <appender name="RollingFileAppender" type="log4net.Appender.RollingFileAppender, log4net" >
        <param name="File" value="logs\Test.log" />
        <param name="AppendToFile" value="true" />
        <param name="RollingStyle" value="Size" />
        <param name="MaxSizeRollBackups" value="1" />
        <param name="MaximumFileSize" value="10MB" />
        <param name="StaticLogFileName" value="true" />

        <layout type="log4net.Layout.PatternLayout, log4net">
            <param name="ConversionPattern" value="%date{dd.MM.yyyy HH:mm:ss,fff} - %4thread - %-5level - %logger - %class.%method : %message%newline" />
        </layout>

    </appender>

    <root>
        <priority value="ALL" />

        <appender-ref ref="RollingFileAppender" />
    </root>

</log4net>


And this is the corresponding log, I miss the "Main()" method name.

16.09.2010 15:27:46,739 -   10 - DEBUG - ConsoleApplication1.Program - Common.Logging.Factory.AbstractLogger.Debug : testmessage

What am I doing wrong?
-- 
Hi, ich bin SeboStone!

Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

[Netcommon-developer] Runtime error with custom LoggerFactoryAdapter/Logger

[Geoghegan, W. A (Willie) <wil...@in...>]

Hello,

I am currently evaluating Common.Logging.  I have implemented a custom
LoggerFactoryAdapter/Logger to wrap a logger that I wrote that logs via
System.Diagnostics.TraceSource.  Because the underlying logger is based
on TraceSources, my factory does not require any additional
configuration parameters.  I created my logger factory adapter by
subclassing from AbstractCachingLoggerFactoryAdapter and implementing
the constructor which takes the NameValueCollection and also the
CreateLogger method.

When I configure Common.Logging (via the app.config file) to use my
custom logger factory adapter, I get an exception that says:

"Unable to create instance of type <my fully qualified logger factory
adapter class>.  Possible explanation is lack of zero arg and single arg
NameValueCollection constructors."

The inner exception says "No parameterless constructor defined for this
object".

I do have the NameValueCollection constructor, however, I do not have
any configuration parameters in my app.config file (since my factory
does not require any).  I tried adding a zero arg constructor and got a
compile error that the AbstractCachingLoggerFactoryAdapter does not
contain a constructor that takes 0 arguments.

I have worked around this by simply adding a dummy name/value pair to my
factory adapter's configuration.  It seems like it should be ok to have
no configuration properties and that Common.Logging should be tolerant.


Inside of LogManager.cs in BuildLoggerFactoryAdapterFromLogSettings
around line 303, setting.Properties is tested.  If it is not null and if
setting.Properties.Count > 0, then the adapter is created via the
"NameValueCollection" constructor.  Otherwise, it is created via the
zero arg constructor.

Thanks.

Willie Geoghegan.

[Netcommon-developer] When is next release and what will be in it?

[Geoghegan, W. A (Willie) <wil...@in...>]

Please forgive the possible double email.  I subscribed to the list last
week and got my confirmation mail.  When I sent an email to the list
earlier today, I got a message back indicating that it was being held
pending moderator approval because it was by a non-member to a
members-only list.  It might appear to be from a nonmember because I
used an old format (very abbreviated) work email address.  Outgoing
emails are tagged with a newer format email address (full name plus full
company name).  Anyway, I am sending the contents of that email inside
of this email (I have resubscribed with my new email address) to see if
it works.

Hello,

I can see on the Common Infrastructure Libraries for .NET homepage at
SourceForge that the next scheduled release is "June".  The page shows
that it was last updated on 5/4/09.  The download page shows that
Common.Logging 2.0 was most recently updated in Feb 2010.  Does that
mean that the next scheduled release is (was) June 2009?

Are the features listed on the homepage still the next features to be
implemented (partial trust, Azure, Silverlight, trace context support)?

I am currently looking at Common.Logging and SLF (slf.codeplex.com) as
possible solutions for insulating a new project from a specific logging
implementation.  

For some background, we will be targeting .NET 4.0 and higher (i.e. at
this point we don't expect to have a requirement to provide a lot of
legacy support).  We expect to use a lot of Silverlight, WPF, and WCF,
so we would like to be able to log from any or all of these
environments.  At this point, I anticipate that our primary usage of
something like Common.Logging or SLF (or something else) to be to
insulate our source from a dependency on a specific logging library.  I
do not anticipate having to bridge between logging systems.  Of course
that could change if we use a third party library/app that uses a
specific logging library.  Right now we expect to use a static logging
manager (e.g. LogManager) rather than getting logger(s) by DI.

We are still pretty early in the design phase and are doing a lot of
research and prototyping.  I am coming from a limited .NET background,
having spent the past 10+ years programming in COM and VB6.

Looking for any tips for particularly thorny issues related to logging
and Silverlight and WCF.

Thanks for any info regarding the next release of Common.Logging and
thanks for any tips that anyone is willing to share.

Willie Geoghegan.

Re: [Netcommon-developer] hi

[Erich E. <eei...@gm...>]

you need to set global properties for this in log4net - please see the
log4net documentation on this

 

-Erich

 

From: Fatih Ender [mailto:fat...@gm...] 
Sent: 29 July 2010 10:16
To: net...@li...
Subject: [Netcommon-developer] hi

 

how can i add my own properties to log.
for ex: username and ip values...

    <appender name="ConsoleAppender"
type="log4net.Appender.ConsoleAppender">
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%date -> %property[username]@%property[ip]
 - %message%newline" />
      </layout>
    </appender>
 

thanx

[Netcommon-developer] hi

[Fatih E. <fat...@gm...>]

how can i add my own properties to log.
for ex: username and ip values...

     <appender  name="ConsoleAppender"  type="log4net.Appender.ConsoleAppender">
       <layout  type="log4net.Layout.PatternLayout">
         <conversionPattern  value="%date ->  %property[username]@%property[ip]
  - %message%newline"  />
       </layout>
     </appender>

thanx