You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Matthew Lee (JIRA)" <ji...@apache.org> on 2007/12/18 16:58:43 UTC

[jira] Created: (LOG4NET-130) AdoNetAppender fails to insert the correct timestamp when logging from a web service.

AdoNetAppender fails to insert the correct timestamp when logging from a web service.
-------------------------------------------------------------------------------------

                 Key: LOG4NET-130
                 URL: https://issues.apache.org/jira/browse/LOG4NET-130
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
         Environment: C# web service running on Windows Server 2003 using the .Net 2.0 Framework.
            Reporter: Matthew Lee


I have a C# console application which calls a C# web service.  Both applications are written under the .Net 2.0 Framework.  Both applications are using a "global" xml configuration file, which is loaded via the XmlConfigurator.  The configuration uses 2 appenders, the AdoNetAppender and the EventLogAppender.

The "global" configuration file that I mentioned earlier is an xml file that is hosted by our local web server.  Each application takes the configuration file from the URL specified.  Then each application injects its own name in the ApplicationName section of the EventLogAppender.  This is done so that the names in the EventLog are meaningful instead of having a GUID for the application name.

The code looks like this:

        private static readonly log4net.ILog oLog = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

        static int Main(string[] args)
        {
            /*******************************************************************/
            // Setup the log4net configuration.  Here we'll use a cool trick. 
            // Log4net can be setup to load it's settings from an xml document
            // which we'll get from a URL.  This allows us to update the config
            // whenever we want to without redeploying individual programs.
            /*******************************************************************/
            XmlDocument oDoc = new XmlDocument();
            oDoc.Load(Properties.Settings.Default.log4net_config_url);
            foreach (XmlNode oNode in oDoc.SelectNodes("log4net/appender[@name='EventLogAppender']"))
            {
                if (oNode != null)
                {
                        XmlAttribute oValueAttribute = oDoc.CreateAttribute("value");
                        oValueAttribute.Value = oLog.Logger.Name.ToString();

                        XmlNode oNameNode = oDoc.CreateNode(XmlNodeType.Element, "applicationName", "");
                        oNameNode.Attributes.Append(oValueAttribute);
                        oNode.AppendChild(oNameNode);
                }
            }
            log4net.Config.XmlConfigurator.Configure(oDoc.DocumentElement);

The problems that I am having are that:

1.	If the web service is not loaded in memory, the first call to the web service does not log anything to the database.  I do, however, get events in the Application Event Log on the web server.

2.	After the first call to the web service, on subseqent web service calls the AdoNetAppender inserts records with timestamps left over from the prvious call.  So for example, if I call the web service for the first time at 1:22; nothing is inserted into the database from the web service.  If my second call is at 1:26, the records that the web service inserts have a timestamp of 1:22.  If I call the web service a 3rd time at 1:29, the records the web service insert have a timestamp of 1:26.

3.	Changes to hosted XML file (which are then read by the XmlConfigurator) do not take effect until the web service is reloaded in IIS.  I do have the [assembly: log4net.Config.XmlConfigurator(Watch = true)] flag set.  But, I'm guessing that because the assembly stays loaded in IIS, this doesn't really have much effect.

I suspect that the problems in #1 and #2 are defects of the AdoNetAppender.  I suspect that problem #3 is something that I'll have to live with.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.