Re: Log4Net 1.3.0
On 2013-11-07, Stefan Bodewig wrote: > I'll try to find some time for a short triage and come back. Found one old bug that looked easy and relatively safe to fix, so I did just that. I don't intend to put more changes into the release myself. Unless anybody else wants to do additional work, I'll cut the release over the weekend. Stefan
[jira] [Resolved] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows
[ https://issues.apache.org/jira/browse/LOG4NET-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-132. Resolution: Fixed > Environment variables are mistakenly case sensitive on windows > -- > > Key: LOG4NET-132 > URL: https://issues.apache.org/jira/browse/LOG4NET-132 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows, .Net 3.5 >Reporter: Matthew Gabeler-Lee >Assignee: Stefan Bodewig >Priority: Minor > Fix For: 1.2.13 > > > On windows, environment variables are meant to be case insensitive. Because > of this, in some contexts, a special IDictionary class that lowercases all > the keys is used to manipulate environment variables, specifically > ProcessStartInfo.EnvironmentVariables. > The upshot of this, for me, is that when running under the profiler I have, > all the environment variables get lowercased, and my logging configuration is > broken, because TEMP is now temp, and log4net is treating the environment > variables in a case sensitive manner, from using > Environment.GetEnvironmentVariables(), which creates a normal case sensitive > Hashtable object. > It seems that, on windows, the result of > Environment.GetEnvironmentVariables() should be copied into a > StringDictionary to get proper case insensitive behavior. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (LOG4NET-363) System.ObjectDisposedException thrown in log4net.Layout.XmlLayoutSchemaLog4j.FormatXml ln 47
[
https://issues.apache.org/jira/browse/LOG4NET-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved LOG4NET-363.
Resolution: Duplicate
Fix Version/s: 1.2.12
> System.ObjectDisposedException thrown in
> log4net.Layout.XmlLayoutSchemaLog4j.FormatXml ln 47
>
>
> Key: LOG4NET-363
> URL: https://issues.apache.org/jira/browse/LOG4NET-363
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
>Affects Versions: 1.2.11
> Environment: IIS 7.0
>Reporter: David Perlman
>Priority: Minor
> Labels: nullpointerexception
> Fix For: 1.2.12
>
>
> On line 47 in XmlLayoutSchemaLog4j there is a reference to the
> LoggingEvent.Identity property. If this call is made after the web request is
> finished (from a different thread) the logger throws (below the exception is
> my sad workaround):
> log4net:ERROR [UdpAppender] ErrorCode: WriteFailure. Unable to send logging
> event to remote host --- on port .
> System.ObjectDisposedException: Safe handle has been closed
>at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean&
> success)
>at Microsoft.Win32.Win32Native.GetTokenInformation(SafeTokenHandle
> TokenHandle, UInt32 TokenInformationClass, SafeLocalAllocHandle
> TokenInformation, UInt32 TokenInformationLength, UInt32& ReturnLength)
>at
> System.Security.Principal.WindowsIdentity.GetTokenInformation(SafeTokenHandle
> tokenHandle, TokenInformationClass tokenInformationClass)
>at System.Security.Principal.WindowsIdentity.get_User()
>at System.Security.Principal.WindowsIdentity.GetName()
>at System.Security.Principal.WindowsIdentity.get_Name()
>at log4net.Core.LoggingEvent.get_Identity()
>at log4net.Layout.XmlLayoutSchemaLog4j.FormatXml(XmlWriter writer,
> LoggingEvent loggingEvent)
>at log4net.Layout.XmlLayoutBase.Format(TextWriter writer, LoggingEvent
> loggingEvent)
>at log4net.Appender.AppenderSkeleton.RenderLoggingEvent(LoggingEvent
> loggingEvent)
>at log4net.Appender.UdpAppender.Append(LoggingEvent loggingEvent)
> Workaround -
> // translate identity name
> // When logging on a thread that continues (asynchronously) after
> the web request is finished this will throw the logging
> try
> {
> if (loggingEvent.Identity != null &&
> loggingEvent.Identity.Length > 0 &&
>
> loggingEvent.LookupProperty(LoggingEvent.IdentityProperty) == null)
> {
>
> loggingEvent.GetProperties()[LoggingEvent.IdentityProperty] =
> loggingEvent.Identity ?? "identity lost";
> }
> }
> catch { }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (LOG4NET-383) Log4Net.Error throws VerificationException - Operation could destabilize the runtime
[ https://issues.apache.org/jira/browse/LOG4NET-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-383. Resolution: Fixed Fix Version/s: 1.2.12 > Log4Net.Error throws VerificationException - Operation could destabilize the > runtime > > > Key: LOG4NET-383 > URL: https://issues.apache.org/jira/browse/LOG4NET-383 > Project: Log4net > Issue Type: Bug >Affects Versions: 1.2.10, 1.2.11 > Environment: IIS 7.5 / Win 2008 R2 > .Net 4.0 > MVC3 and WCF applications >Reporter: Arun > Fix For: 1.2.12 > > > We are running into this issue when we log errors/fatal message using > log4net. > > System.Security.VerificationException: Operation could destabilize the > > runtime.at log4net.Core.LogImpl.Fatal(Object message, Exception > > exception) > Strangely this happens only when we log as Error/Fatal, Info and Debug > messages log perfectly fine. Because of this exception, the real exceptions > are getting masked and its making it very hard for us to debug in deployed > environments. > I have tried searching online but to no avail. Any help is appreciated. > Environment details: > IIS 7.5 / Win 2008 R2 > .Net 4.0 > MVC3 and WCF applications > Here is the logging configuration- > > > > > type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/> > > >type="log4net.Appender.RollingFileAppender"> > > > > > > > > > > > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LOG4NET-387) Mysterious characters in the log file
[ https://issues.apache.org/jira/browse/LOG4NET-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-387: --- Priority: Critical (was: Blocker) Fix Version/s: (was: 1.2.10) I'm sure this issue is important to yoi, but so far you are the only one that has ever reported it which makes it likely to be an environment or application issue - that's why I've reduced the severity. Is there anything we can do to reproduce this? It really looks as if something was spitting a binary into your logfile, maybe you are logging some user input? Does the last log message before the trouble starts to happen give any hint? > Mysterious characters in the log file > - > > Key: LOG4NET-387 > URL: https://issues.apache.org/jira/browse/LOG4NET-387 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows XP, .Net 2.0 Framework, Windows Service > Application >Reporter: Baha >Priority: Critical > Labels: bug > > We have a windows service application in production. This windows service is > logging greatly with no issues, but sometimes it starts logging mysterious > characters like in this screenshot: > https://files.secureserver.net/0sq7H3khXnoq67 > To fix this, we clean the log file, and restart the windows service again, > but in this way, we are loosing most of the logs (specially the > exception/error fired by the windows service). > Any idea on this will be greatly appreciated. > Baha Ashour, > RFID Enabled Solutions > b...@resrfid.com -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows
[ https://issues.apache.org/jira/browse/LOG4NET-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-132: --- Fix Version/s: (was: 1.2 Maintenance Release) 1.2.13 > Environment variables are mistakenly case sensitive on windows > -- > > Key: LOG4NET-132 > URL: https://issues.apache.org/jira/browse/LOG4NET-132 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows, .Net 3.5 >Reporter: Matthew Gabeler-Lee >Priority: Minor > Fix For: 1.2.13 > > > On windows, environment variables are meant to be case insensitive. Because > of this, in some contexts, a special IDictionary class that lowercases all > the keys is used to manipulate environment variables, specifically > ProcessStartInfo.EnvironmentVariables. > The upshot of this, for me, is that when running under the profiler I have, > all the environment variables get lowercased, and my logging configuration is > broken, because TEMP is now temp, and log4net is treating the environment > variables in a case sensitive manner, from using > Environment.GetEnvironmentVariables(), which creates a normal case sensitive > Hashtable object. > It seems that, on windows, the result of > Environment.GetEnvironmentVariables() should be copied into a > StringDictionary to get proper case insensitive behavior. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows
[ https://issues.apache.org/jira/browse/LOG4NET-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig reassigned LOG4NET-132: -- Assignee: Stefan Bodewig > Environment variables are mistakenly case sensitive on windows > -- > > Key: LOG4NET-132 > URL: https://issues.apache.org/jira/browse/LOG4NET-132 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows, .Net 3.5 >Reporter: Matthew Gabeler-Lee >Assignee: Stefan Bodewig >Priority: Minor > Fix For: 1.2.13 > > > On windows, environment variables are meant to be case insensitive. Because > of this, in some contexts, a special IDictionary class that lowercases all > the keys is used to manipulate environment variables, specifically > ProcessStartInfo.EnvironmentVariables. > The upshot of this, for me, is that when running under the profiler I have, > all the environment variables get lowercased, and my logging configuration is > broken, because TEMP is now temp, and log4net is treating the environment > variables in a case sensitive manner, from using > Environment.GetEnvironmentVariables(), which creates a normal case sensitive > Hashtable object. > It seems that, on windows, the result of > Environment.GetEnvironmentVariables() should be copied into a > StringDictionary to get proper case insensitive behavior. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: Log4Net 1.3.0
>> If there is, I'd be happy to wait anouther week, otherwise I'd proceed >> with the release process and rather try to get trunk back into a >> releasable state for a quick 1.3.0 afterwards. > Not anytime soon, sorry. Understood. I'll have to re-tag anyway as my fix for what became LOG4NET-404 was incomplete (that's what you get for not even compiling after a partial merge). I'll try to find some time for a short triage and come back. Stefan
[jira] [Resolved] (LOG4NET-404) assemblies for .NET 3.5 are missing ILogExtensions
[ https://issues.apache.org/jira/browse/LOG4NET-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-404. Resolution: Fixed > assemblies for .NET 3.5 are missing ILogExtensions > -- > > Key: LOG4NET-404 > URL: https://issues.apache.org/jira/browse/LOG4NET-404 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.12 >Reporter: Stefan Bodewig > Fix For: 1.2.13 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (LOG4NET-404) assemblies for .NET 3.5 are missing ILogExtensions
Stefan Bodewig created LOG4NET-404: -- Summary: assemblies for .NET 3.5 are missing ILogExtensions Key: LOG4NET-404 URL: https://issues.apache.org/jira/browse/LOG4NET-404 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.12 Reporter: Stefan Bodewig Fix For: 1.2.13 -- This message was sent by Atlassian JIRA (v6.1#6144)
AW: Log4Net 1.3.0
>On 2013-11-07, Dominik Psenner wrote: > >>> On 2013-11-06, Dominik Psenner wrote: > Maybe we can craft some other small and easy fixes that we can ship with 1.2.13. > >>> Oh, even though I've already tagged the sources in svn don't let that >>> hold you back, tags are cheap. Look through JIRA if you see anything >>> you feel fits and we'll go from there. > >> I may spare some time in the weekend, thus feel free to go on. > >Do you think you can have a quick look to see whether there is any >"quick fix" kind of ticket - to me nothing jumps out right now. > >If there is, I'd be happy to wait anouther week, otherwise I'd proceed >with the release process and rather try to get trunk back into a >releasable state for a quick 1.3.0 afterwards. Not anytime soon, sorry.
Re: Log4Net 1.3.0
On 2013-11-07, Dominik Psenner wrote: >> On 2013-11-06, Dominik Psenner wrote: >>> Maybe we can craft some other small and easy fixes that we can ship with >>> 1.2.13. >> Oh, even though I've already tagged the sources in svn don't let that >> hold you back, tags are cheap. Look through JIRA if you see anything >> you feel fits and we'll go from there. > I may spare some time in the weekend, thus feel free to go on. Do you think you can have a quick look to see whether there is any "quick fix" kind of ticket - to me nothing jumps out right now. If there is, I'd be happy to wait anouther week, otherwise I'd proceed with the release process and rather try to get trunk back into a releasable state for a quick 1.3.0 afterwards. Stefan
