Re: Distribution Formats
On 2011-09-09, Ron Grabowski wrote: > New key? I think I Nicko sent me the current assembly keya long time > ago. People always complain when keys change Search a while back through your mail backlog (about a month). There is consensus to move to a new key that is deliberately not kept secret so people can build their own patched versions of log4net and get the same strong name. We will explain that the key does not provide any sort of security promise - people are supposed to verify the PGP signature for that. Some people may rely on the implied promise of "this is the real thing" of the old key which is why Curt asked us to not make the old key public (this is the only reason why we need a new key). 1.2.11 and maybe later releases should be available with two different strong names. Stefan
Re: Forth digit in version number
On 2011-09-08, Dominik Guder wrote: > using nant for retreiving svn revision to property svn.revision: > use svn log (repository access) >output="_svnrevision.xml" failonerror="true" > > > > > > > xpath="/log/logentry/@revision" > property="svn.revision" > failonerror="true"/> It is likely fair to assume that whoever uses NAnt also has a svn command line client around - or I need to provide some sort of fallback if it isn't. Thanks. Stefan
Re: Forth digit in version number
On 2011-09-08, Michael Schall wrote: >> Interesting. How do you integrate this with your build process? > I can give you specifics if you want, but we use MSBuild and MSBuild > Community Tasks (http://msbuildtasks.tigris.org/)... > We have a target that uses the SvnInfo task to find the SubersionRevision > and RepositoryPath properties, and use the FileUpdate task update the > AssemblyInfo files as needed. I see. For our NAnt build Dominik's response should point me into the best direction. Thanks Stefan
[jira] [Commented] (LOG4NET-283) OnlyOnceErrorHandler is not subclass-friendly
[
https://issues.apache.org/jira/browse/LOG4NET-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100935#comment-13100935
]
Ron Grabowski commented on LOG4NET-283:
---
I could see sending an email when the appender goes off-line being handy:
SendEmailOnlyOnceErrorHandler
> OnlyOnceErrorHandler is not subclass-friendly
> -
>
> Key: LOG4NET-283
> URL: https://issues.apache.org/jira/browse/LOG4NET-283
> Project: Log4net
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.2.10
> Environment: Windows 7, IIS 7, .Net 3.5, C#
>Reporter: Randar Puust
> Fix For: 1.2 Maintenance Release
>
>
> If you ever try to use the ErrorHandler attribute with a custom error
> handler, it won't write out the messages. For example:
>
>
> Where the class is defined as:
> public class LogWriterErrorHandler : OnlyOnceErrorHandler
> {
>
> public new void Error(string message)
> {
> Error(message, null);
> }
> public new void Error(string message, Exception e)
> {
> Error(message, e, ErrorCode.GenericFailure);
> }
> public new void Error(string message, Exception e, ErrorCode
> errorCode)
> {
> // write to a file here
> }
> }
>
> This was specified as a fix on a few posts like this
> http://www.mail-archive.com/log4net-user@logging.apache.org/msg04378.html and
> there hasn't been anything to correct it.
> The reason this won't work is that Error is not virtual. Although the
> LogWriterErrorHandler is instantiated and the constructor is called, when the
> appender makes a call to this.ErrorHandler.Error, it calls the base class of
> OnlyOnceErrorHandler and not LogWriterErrorHandler.
> I would recommend you make the Error methods in AppenderSkeleton virtual so
> that they can be overriden. Otherwise, what is the value of even having the
> ErrorHandler attribute available on the appender?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Distribution Formats
New key? I think I Nicko sent me the current assembly keya long time ago. People always complain when keys change From: Stefan Bodewig To: log4net-dev@logging.apache.org Sent: Thursday, September 8, 2011 12:26 AM Subject: Distribution Formats Hi all, 1.2.10 is distributed as a single ZIP with source and binaries for all supported platforms. "Normal" ASF procedure is to have separate downloads for source-only and binary-plus-doc releases and to provide ZIPs as well as tar.gz tarballs. How do we want to package 1.2.11? I personally would stick with ZIPs only but create three archives: source only, binaries signed with new key plus docs, binaries signed with old key plus docs. Any other preferences? Stefan
Re: Forth digit in version number
Am 08.09.2011 17:01, schrieb Michael Schall: We set the forth digit to 0 for the AssemblyVersion attribute and SVN revision number for the AssemblyFileVersion attribute. This way you can slipstream fixes without breaking compatibility with other's code, but you still have the revision number if you want it. +1 so do we in office. using nant for retreiving svn revision to property svn.revision: use svn log (repository access) or using svn info (without repository access, but should be updated before: hth Dominik -- The answer to the great question of life, the universe and everything is 42 (Douglas Adams)
Re: Forth digit in version number
> I'd rather release 1.2.NEXT then. YMMV. We had issues where if the AssemblyVersion didn't match exactly, .Net would not load the assemblies without a redirect. > Interesting. How do you integrate this with your build process? I can give you specifics if you want, but we use MSBuild and MSBuild Community Tasks (http://msbuildtasks.tigris.org/)... We have a target that uses the SvnInfo task to find the SubersionRevision and RepositoryPath properties, and use the FileUpdate task update the AssemblyInfo files as needed. Mike On Thu, Sep 8, 2011 at 11:13 AM, Stefan Bodewig wrote: > On 2011-09-08, Michael Schall wrote: > > > We set the forth digit to 0 for the AssemblyVersion attribute and SVN > > revision number for the AssemblyFileVersion attribute. This way you can > > slipstream fixes without breaking compatibility with other's code, but > you > > still have the revision number if you want it. > > I'd rather release 1.2.NEXT then. YMMV. > > > We also add the actual SVN url to the AssemblyDescription so you can grab > > the exact code easily. > > Interesting. How do you integrate this with your build process? > > I was thinking about using "svn info" or even parsing the .svn contents > but don't really feel comfortable enough with NAnt to do that (and don't > know whether things like TutroiseSvn or AnkhSvn or whatever provide a > svn command line client for svn info to work). > > Stefan >
[jira] [Reopened] (LOG4NET-209) XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement
[ https://issues.apache.org/jira/browse/LOG4NET-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Gabeler-Lee reopened LOG4NET-209: - protected -- oops, forgot I'd done a little subclass to access that ;) I'll write up a patch for option 1, and be sure to retain compatibility in default modes. Unit tests are good, I'll include at least one in for the new mode :) > XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement > --- > > Key: LOG4NET-209 > URL: https://issues.apache.org/jira/browse/LOG4NET-209 > Project: Log4net > Issue Type: Bug > Components: Other >Affects Versions: 1.2.10 > Environment: .NET 3.5 SP1 >Reporter: Matthew Gabeler-Lee > > FormatXml calls WriteStartElement using prefixed element names (e.g. > "log4net:event"), but it calls the overload of WriteStartElement that expects > a local name. Thus, if it writes to an xml writer that actually checks such > things, it crashes. Instead, it should call the overload that separates the > prefix from the local name. E.g.: writer.WriteStartElement(this.m_prefix, > this.m_elmEvent, null). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Forth digit in version number
On 2011-09-08, Michael Schall wrote: > We set the forth digit to 0 for the AssemblyVersion attribute and SVN > revision number for the AssemblyFileVersion attribute. This way you can > slipstream fixes without breaking compatibility with other's code, but you > still have the revision number if you want it. I'd rather release 1.2.NEXT then. YMMV. > We also add the actual SVN url to the AssemblyDescription so you can grab > the exact code easily. Interesting. How do you integrate this with your build process? I was thinking about using "svn info" or even parsing the .svn contents but don't really feel comfortable enough with NAnt to do that (and don't know whether things like TutroiseSvn or AnkhSvn or whatever provide a svn command line client for svn info to work). Stefan
[jira] [Commented] (LOG4NET-209) XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement
[ https://issues.apache.org/jira/browse/LOG4NET-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100417#comment-13100417 ] Stefan Bodewig commented on LOG4NET-209: FormatXml is protected ;-) I haven't written the code and haven't been around when it was written, so I don't know why it it works as it does. It looks as if FormatXml was only expected to be used as part of the Format template method in XmlLayoutBase (and has to be protected for things to work, of course). Actually I had started to implement either of your two approaches before I commented and then ran into the exception (i overlooked the Namespace=false line intially). The unit test relies on the behavior that no prefix will be added unless ActivateOptions has been called (which the test doesn't do), not sure whether this is imporatant to retain. Yes, I'd be willing to accept a patch if it was backwards compatible and passes the existing tests without changing them. Bonus points if you add new tests 8-) Even though I'd prefer to get rid of the pre-built element names option 1 seems to be more in line with the original intentions of the existing code and I feel conservative right now - at least until we've released 1.2.11. > XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement > --- > > Key: LOG4NET-209 > URL: https://issues.apache.org/jira/browse/LOG4NET-209 > Project: Log4net > Issue Type: Bug > Components: Other >Affects Versions: 1.2.10 > Environment: .NET 3.5 SP1 >Reporter: Matthew Gabeler-Lee > > FormatXml calls WriteStartElement using prefixed element names (e.g. > "log4net:event"), but it calls the overload of WriteStartElement that expects > a local name. Thus, if it writes to an xml writer that actually checks such > things, it crashes. Instead, it should call the overload that separates the > prefix from the local name. E.g.: writer.WriteStartElement(this.m_prefix, > this.m_elmEvent, null). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-209) XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement
[ https://issues.apache.org/jira/browse/LOG4NET-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100408#comment-13100408 ] Matthew Gabeler-Lee commented on LOG4NET-209: - I am calling FormatXml directly. My personal use case is collecting events into a larger XmlDocument, attempting to use code like this: // XmlElement parentElement = ... // LoggingEvent[] events // arg to BufferingAppenderSkeleton.SendBuffer using (var nw = parentElement.CreateNavigator().AppendChild()) for (int i = 0; i < events.Length; ++i) FormatXml(nw, events[i]); If FormatXml is not meant to be generally useable, it shouldn't be public. I can write up a patch to fix this problem, as having looked at the code it doesn't appear all that difficult. Would you accept such a patch? If so, I see two strategies for controlling the namespace behavior: 1) Add a property to XmlLayout to control the element name building at ActivateOptions time and the overload that is called at FormatXml time (less flexible, marginally better performance) 2) Never pre-build combined prefix:elementname at ActivateOptions time and detect the mode at each call to FormatXml (more flexible, marginally worse performance) > XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement > --- > > Key: LOG4NET-209 > URL: https://issues.apache.org/jira/browse/LOG4NET-209 > Project: Log4net > Issue Type: Bug > Components: Other >Affects Versions: 1.2.10 > Environment: .NET 3.5 SP1 >Reporter: Matthew Gabeler-Lee > > FormatXml calls WriteStartElement using prefixed element names (e.g. > "log4net:event"), but it calls the overload of WriteStartElement that expects > a local name. Thus, if it writes to an xml writer that actually checks such > things, it crashes. Instead, it should call the overload that separates the > prefix from the local name. E.g.: writer.WriteStartElement(this.m_prefix, > this.m_elmEvent, null). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Forth digit in version number
We set the forth digit to 0 for the AssemblyVersion attribute and SVN revision number for the AssemblyFileVersion attribute. This way you can slipstream fixes without breaking compatibility with other's code, but you still have the revision number if you want it. We also add the actual SVN url to the AssemblyDescription so you can grab the exact code easily. Mike On Wed, Sep 7, 2011 at 11:30 PM, Stefan Bodewig wrote: > Hi, > > I don't expect us to release betas or any other kind of two releases > that would only differ in the forth digit of the version number. So we > could simply set it to 0 (which I think currently happens in trunk, > didn't check). > > Right now I'm afraid I won't be able to build all binaries on the same > machine so ".*" would result in different versions depending on the > platform. > > An alternative would be to use the svn revision number. > > Other ideas? > > Stefan >
Re: Distribution Formats
i Agree. Javier Sánchez R. On Thu, Sep 8, 2011 at 06:49, Roy Chastain wrote: > I agree (+1) > > -- > Roy Chastain > > > > > -Original Message- > From: Stefan Bodewig [mailto:bode...@apache.org] > Sent: Thursday, September 08, 2011 00:26 > To: log4net-dev@logging.apache.org > Subject: Distribution Formats > > Hi all, > > 1.2.10 is distributed as a single ZIP with source and binaries for all > supported platforms. "Normal" ASF procedure is to have separate > downloads for source-only and binary-plus-doc releases and to provide > ZIPs as well as tar.gz tarballs. > > How do we want to package 1.2.11? > > I personally would stick with ZIPs only but create three archives: > source only, binaries signed with new key plus docs, binaries signed > with old key plus docs. > > Any other preferences? > > Stefan >
[jira] [Resolved] (LOG4NET-244) SmtpAppender.To Property has incorrect delimiter
[ https://issues.apache.org/jira/browse/LOG4NET-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-244. Resolution: Duplicate Actually "semicolon" was/is correct on .NET 1.1 and "comma" is correct on more recent frameworks when System.Net.Mail is used. > SmtpAppender.To Property has incorrect delimiter > > > Key: LOG4NET-244 > URL: https://issues.apache.org/jira/browse/LOG4NET-244 > Project: Log4net > Issue Type: Bug > Components: Documentation >Affects Versions: 1.2.10 > Environment: Win 2003 Server Running ASP.net application on framework > 2.0 >Reporter: Charles Chatt > Fix For: 1.2.11 > > > SmtpAppender.To Property has an incorrect delimiter listed in the > documentation. When the semicolon delimiter is used (per spec) the > application will not send emails to the list. Yet, if the delimiter is > changed to a comma, everything works fine. > Here is the link to the documentation which specifies the semicolon > delimiter. > http://logging.apache.org/log4net/release/sdk/log4net.Appender.SmtpAppender.To.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-244) SmtpAppender.To Property has incorrect delimiter
[ https://issues.apache.org/jira/browse/LOG4NET-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-244: --- Component/s: (was: Appenders) Documentation > SmtpAppender.To Property has incorrect delimiter > > > Key: LOG4NET-244 > URL: https://issues.apache.org/jira/browse/LOG4NET-244 > Project: Log4net > Issue Type: Bug > Components: Documentation >Affects Versions: 1.2.10 > Environment: Win 2003 Server Running ASP.net application on framework > 2.0 >Reporter: Charles Chatt > Fix For: 1.2.11 > > > SmtpAppender.To Property has an incorrect delimiter listed in the > documentation. When the semicolon delimiter is used (per spec) the > application will not send emails to the list. Yet, if the delimiter is > changed to a comma, everything works fine. > Here is the link to the documentation which specifies the semicolon > delimiter. > http://logging.apache.org/log4net/release/sdk/log4net.Appender.SmtpAppender.To.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (LOG4NET-212) Threading bug in the PatternConverter.cs
[ https://issues.apache.org/jira/browse/LOG4NET-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100271#comment-13100271 ] Stefan Bodewig edited comment on LOG4NET-212 at 9/8/11 12:50 PM: - The same is true for AppenderSkeleton.RenderLoggingEvent(LoggingEvent). I agree that proper locking would impact performance more than simply creating new StringWriters as needed. I'll set up some simplistic multi-threaded test scenario. was (Author: bodewig): The same is true fro AppenderSkeleton.RenderLoggingEvent(LoggingEvent). I agree that proper locking would impact performance more than simply creating new StringWriters as needed. I'll set up some simplistic multi-threaded test scenario. > Threading bug in the PatternConverter.cs > > > Key: LOG4NET-212 > URL: https://issues.apache.org/jira/browse/LOG4NET-212 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows, .NET 2.0 / 3.5, C# >Reporter: Jerry van Leeuwen > Fix For: 1.2.11 > > > Every once in a while I get the following exception: >System.ArgumentOutOfRangeException: Index and length must refer to a > location within the string. > Parameter name: length >at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 > length, Boolean fAlwaysCopy) >at System.Text.StringBuilder.ToString(Int32 startIndex, Int32 length) >at log4net.Util.PatternConverter.Format(TextWriter writer, Object > state) in xxx\Log4Net\src\Util\PatternConverter.cs:line 187 >at log4net.Layout.PatternLayout.Format(TextWriter writer, LoggingEvent > loggingEvent) in xxx\Log4Net\src\Layout\PatternLayout.cs:line 1009 >at > Nemmco.Common.Initialization.Internal.NemLoggingAppender.Execute(DateTime > lastTrigger, DateTime currentTrigger) in > xxxInitialization\Internal\InitializationLogging.cs:line 765 > --snip-- > From my own investigation it looks like the problem occurs because the shared > string buffer (from the m_formatWriter.GetStringBuilder() call) may end up in > a state where its size is adjusted differently on separate threads, causing > one thread to over-estimate the available length. > I wonder if the re-use of a StringWriter / StringBuilder in this scenario > actually outweighs the threading implications? The simplest fix would be to > replace use of m_formatWriter with use of a local StringWriter / > StringBuilder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-212) Threading bug in the PatternConverter.cs
[ https://issues.apache.org/jira/browse/LOG4NET-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100271#comment-13100271 ] Stefan Bodewig commented on LOG4NET-212: The same is true fro AppenderSkeleton.RenderLoggingEvent(LoggingEvent). I agree that proper locking would impact performance more than simply creating new StringWriters as needed. I'll set up some simplistic multi-threaded test scenario. > Threading bug in the PatternConverter.cs > > > Key: LOG4NET-212 > URL: https://issues.apache.org/jira/browse/LOG4NET-212 > Project: Log4net > Issue Type: Bug > Components: Core >Affects Versions: 1.2.10 > Environment: Windows, .NET 2.0 / 3.5, C# >Reporter: Jerry van Leeuwen > Fix For: 1.2.11 > > > Every once in a while I get the following exception: >System.ArgumentOutOfRangeException: Index and length must refer to a > location within the string. > Parameter name: length >at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 > length, Boolean fAlwaysCopy) >at System.Text.StringBuilder.ToString(Int32 startIndex, Int32 length) >at log4net.Util.PatternConverter.Format(TextWriter writer, Object > state) in xxx\Log4Net\src\Util\PatternConverter.cs:line 187 >at log4net.Layout.PatternLayout.Format(TextWriter writer, LoggingEvent > loggingEvent) in xxx\Log4Net\src\Layout\PatternLayout.cs:line 1009 >at > Nemmco.Common.Initialization.Internal.NemLoggingAppender.Execute(DateTime > lastTrigger, DateTime currentTrigger) in > xxxInitialization\Internal\InitializationLogging.cs:line 765 > --snip-- > From my own investigation it looks like the problem occurs because the shared > string buffer (from the m_formatWriter.GetStringBuilder() call) may end up in > a state where its size is adjusted differently on separate threads, causing > one thread to over-estimate the available length. > I wonder if the re-use of a StringWriter / StringBuilder in this scenario > actually outweighs the threading implications? The simplest fix would be to > replace use of m_formatWriter with use of a local StringWriter / > StringBuilder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-209) XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement
[ https://issues.apache.org/jira/browse/LOG4NET-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-209. Resolution: Not A Problem Fix Version/s: (was: 1.2.11) XmlLayoutBase sets XmlTextWriter.Namespace to false and thus disables all namespace handling. In fact using one of the other overloads of WriteStartElement will result in an exception. Unless you invoke FormatXml directly the XmlWriter will always be the one configured in XmlLayoutBase.Format so the problem of an XmlWriter that wouldn't allow the localname to contain a colon should never happen. > XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement > --- > > Key: LOG4NET-209 > URL: https://issues.apache.org/jira/browse/LOG4NET-209 > Project: Log4net > Issue Type: Bug > Components: Other >Affects Versions: 1.2.10 > Environment: .NET 3.5 SP1 >Reporter: Matthew Gabeler-Lee > > FormatXml calls WriteStartElement using prefixed element names (e.g. > "log4net:event"), but it calls the overload of WriteStartElement that expects > a local name. Thus, if it writes to an xml writer that actually checks such > things, it crashes. Instead, it should call the overload that separates the > prefix from the local name. E.g.: writer.WriteStartElement(this.m_prefix, > this.m_elmEvent, null). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Distribution Formats
I agree (+1) -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Thursday, September 08, 2011 00:26 To: log4net-dev@logging.apache.org Subject: Distribution Formats Hi all, 1.2.10 is distributed as a single ZIP with source and binaries for all supported platforms. "Normal" ASF procedure is to have separate downloads for source-only and binary-plus-doc releases and to provide ZIPs as well as tar.gz tarballs. How do we want to package 1.2.11? I personally would stick with ZIPs only but create three archives: source only, binaries signed with new key plus docs, binaries signed with old key plus docs. Any other preferences? Stefan
[jira] [Resolved] (LOG4NET-296) Patch for .net 4, client profile and a fix for the name resolution bug
[ https://issues.apache.org/jira/browse/LOG4NET-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-296. Resolution: Fixed all subtasks have been closed > Patch for .net 4, client profile and a fix for the name resolution bug > -- > > Key: LOG4NET-296 > URL: https://issues.apache.org/jira/browse/LOG4NET-296 > Project: Log4net > Issue Type: New Feature > Components: Appenders, Builds >Reporter: Tasos Vogiatzoglou > Fix For: 1.2.11 > > Attachments: log4net_clientProfile_net4_netfix.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-305) Use Dns.GetHostEntry rather than Dns.GetHostByName on .NET >= 2.0
[ https://issues.apache.org/jira/browse/LOG4NET-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-305. Resolution: Invalid GetHostByName is only called in code that is used in the 1.x target DLLs - and the alternative isn't vaialble there. Just use log4net compiled for the correct target platform of 2.0. > Use Dns.GetHostEntry rather than Dns.GetHostByName on .NET >= 2.0 > - > > Key: LOG4NET-305 > URL: https://issues.apache.org/jira/browse/LOG4NET-305 > Project: Log4net > Issue Type: Sub-task > Components: Appenders, Builds >Affects Versions: 1.2.10 >Reporter: Stefan Bodewig >Assignee: Stefan Bodewig > Fix For: 1.2.11 > > > GetHostbyName doesn't work properly in IPv6 environments -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-167) ArrayOutOfBounds Exception in MemoryAppender.getEvents()
[ https://issues.apache.org/jira/browse/LOG4NET-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-167. Resolution: Fixed Steve's patch is in as svn revision 1166569. Note that subclasses can still break thread-safety since m_eventsList is protected (and not even readonly). > ArrayOutOfBounds Exception in MemoryAppender.getEvents() > > > Key: LOG4NET-167 > URL: https://issues.apache.org/jira/browse/LOG4NET-167 > Project: Log4net > Issue Type: Bug > Components: Appenders >Affects Versions: 1.2.10 > Environment: Windows Vista and XP. >Reporter: Kenny Clement >Assignee: Ron Grabowski > Fix For: 1.2.11 > > Attachments: MemoryAppenderThreadSafeLocking.patch > > > Getting this every once in a while. > No specific reproduction scenario. > Destination array was not long enough. Check destIndex and length, and the > array's lower bounds. >at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array > destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable) >at System.Collections.ArrayList.ToArray(Type type) >at log4net.Appender.MemoryAppender.GetEvents() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-283) ErrorHandler does not work with custom class
[
https://issues.apache.org/jira/browse/LOG4NET-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100149#comment-13100149
]
Stefan Bodewig commented on LOG4NET-283:
I don't think you want the error methods in AppenderSkeleton to be virtual but
rather the ones in OnlyOnceErrorHandler.
Your custom IErrorHandler should work perfectly well if you implement
IErrorHandler directly without inheriting from OnlyOnceErrorHandler.
Why would you want to extend OnlyOnceErrorHandler at all?
If you want to retain the behavior of not logging more than once per appender
you'd need access to the private m_firstTime field. It would be more logical
to move the code that resides inside the if-block in the three-arg Error method
in OnlyOnceErrorHandler into a new virtual method (FirstError or something like
this) to make things subclass friendly.
I don't see any benefit in extending OnlyOnceErrorHandler if you don't want to
retain the "log once per appender" logic.
I'll change the title and severity as well as the target release of this ticket
accordingly.
> ErrorHandler does not work with custom class
>
>
> Key: LOG4NET-283
> URL: https://issues.apache.org/jira/browse/LOG4NET-283
> Project: Log4net
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.2.10
> Environment: Windows 7, IIS 7, .Net 3.5, C#
>Reporter: Randar Puust
> Fix For: 1.2 Maintenance Release
>
>
> If you ever try to use the ErrorHandler attribute with a custom error
> handler, it won't write out the messages. For example:
>
>
> Where the class is defined as:
> public class LogWriterErrorHandler : OnlyOnceErrorHandler
> {
>
> public new void Error(string message)
> {
> Error(message, null);
> }
> public new void Error(string message, Exception e)
> {
> Error(message, e, ErrorCode.GenericFailure);
> }
> public new void Error(string message, Exception e, ErrorCode
> errorCode)
> {
> // write to a file here
> }
> }
>
> This was specified as a fix on a few posts like this
> http://www.mail-archive.com/log4net-user@logging.apache.org/msg04378.html and
> there hasn't been anything to correct it.
> The reason this won't work is that Error is not virtual. Although the
> LogWriterErrorHandler is instantiated and the constructor is called, when the
> appender makes a call to this.ErrorHandler.Error, it calls the base class of
> OnlyOnceErrorHandler and not LogWriterErrorHandler.
> I would recommend you make the Error methods in AppenderSkeleton virtual so
> that they can be overriden. Otherwise, what is the value of even having the
> ErrorHandler attribute available on the appender?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-283) OnlyOnceErrorHandler is not subclass-friendly
[
https://issues.apache.org/jira/browse/LOG4NET-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-283:
---
Component/s: (was: Appenders)
Core
Fix Version/s: (was: 1.2.11)
1.2 Maintenance Release
Issue Type: Improvement (was: Bug)
Summary: OnlyOnceErrorHandler is not subclass-friendly (was:
ErrorHandler does not work with custom class)
> OnlyOnceErrorHandler is not subclass-friendly
> -
>
> Key: LOG4NET-283
> URL: https://issues.apache.org/jira/browse/LOG4NET-283
> Project: Log4net
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.2.10
> Environment: Windows 7, IIS 7, .Net 3.5, C#
>Reporter: Randar Puust
> Fix For: 1.2 Maintenance Release
>
>
> If you ever try to use the ErrorHandler attribute with a custom error
> handler, it won't write out the messages. For example:
>
>
> Where the class is defined as:
> public class LogWriterErrorHandler : OnlyOnceErrorHandler
> {
>
> public new void Error(string message)
> {
> Error(message, null);
> }
> public new void Error(string message, Exception e)
> {
> Error(message, e, ErrorCode.GenericFailure);
> }
> public new void Error(string message, Exception e, ErrorCode
> errorCode)
> {
> // write to a file here
> }
> }
>
> This was specified as a fix on a few posts like this
> http://www.mail-archive.com/log4net-user@logging.apache.org/msg04378.html and
> there hasn't been anything to correct it.
> The reason this won't work is that Error is not virtual. Although the
> LogWriterErrorHandler is instantiated and the constructor is called, when the
> appender makes a call to this.ErrorHandler.Error, it calls the base class of
> OnlyOnceErrorHandler and not LogWriterErrorHandler.
> I would recommend you make the Error methods in AppenderSkeleton virtual so
> that they can be overriden. Otherwise, what is the value of even having the
> ErrorHandler attribute available on the appender?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-297) AppenderSkeleton.RequiresLayout docs and implementation don't match
[
https://issues.apache.org/jira/browse/LOG4NET-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved LOG4NET-297.
Resolution: Fixed
fixed with svn revision 1166545, will become visible on the website once we
release 1.2.11
> AppenderSkeleton.RequiresLayout docs and implementation don't match
> ---
>
> Key: LOG4NET-297
> URL: https://issues.apache.org/jira/browse/LOG4NET-297
> Project: Log4net
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 1.2.10
>Reporter: Chris Dolan
>Priority: Minor
> Fix For: 1.2.11
>
>
> In AppenderSkeleton.cs:
> ///
> /// This default implementation always returns true.
> ///
> virtual protected bool RequiresLayout
> {
> get { return false; }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-260) difference filter and object render
[ https://issues.apache.org/jira/browse/LOG4NET-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-260. Resolution: Cannot Reproduce I can't see how the functionality of the two could be confused. > difference filter and object render > --- > > Key: LOG4NET-260 > URL: https://issues.apache.org/jira/browse/LOG4NET-260 > Project: Log4net > Issue Type: Task > Components: Documentation >Reporter: Nazish Ali > Fix For: 1.2 Maintenance Release > > > I want clarity between functionality between filter and object rendering -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
