[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:
appender name=Database_Appender type=log4net.Appender.AdoNetAppender
errorHandler type=CHO.Next.Global.LogWriterErrorHandler,
CHO.Next.Global /
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-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] [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-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
[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-tabpanelfocusedCommentId=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] [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] [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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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
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)
exec program=svn.exe workingdir=${svnroot} verbose=false
output=_svnrevision.xml failonerror=true
arg value=log /
arg line=${svnroot} --xml --limit 1 -q /
arg line=--username=foo --password=bar --no-auth-cache /
/exec
sleep milliseconds=500 /
xmlpeek file=_svnrevision.xml
xpath=/log/logentry/@revision
property=svn.revision
failonerror=true/
or using svn info (without repository access, but should be updated before:
exec program=svn.exe workingdir=${svnroot} verbose=false
output=_svnrevision.xml failonerror=true
arg value=info /
arg line=${svnroot} --xml /
/exec
sleep milliseconds=500 /
xmlpeek file=_svnrevision.xml
xpath=/info/entry/commit/@revision
property=svn.revision
failonerror=true/
hth
Dominik
--
The answer to the great question of life,
the universe and everything is 42 (Douglas Adams)
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 bode...@apache.org 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
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
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)
exec program=svn.exe workingdir=${svnroot} verbose=false
output=_svnrevision.xml failonerror=true
arg value=log /
arg line=${svnroot} --xml --limit 1 -q /
arg line=--username=foo --password=bar --no-auth-cache /
/exec
sleep milliseconds=500 /
xmlpeek file=_svnrevision.xml
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
