Re: First JIRA triage run complete - RFA issues

[Stefan Bodewig]

On 2011-09-11, Roy Chastain wrote:

> I picked up Visual NUnit for VS 2010.  Once I installed it and ran the
> tests under it, none of the RFA tests failed.  The plugin indicates that
> 5 are them are "not implemented" and indeed they are not.

Great.  Six of them fail on my Linux box - likely because of hard-coded
line-ends - and I intend to look into that some day, but other than that
this is what I get as well.

> When the test is running under NUnit, the current directory is
> log4Net\tests\bin\debug, yet the logger creates its log file in
> log4Net directory.  Therefore, the two files are different and there
> is no error.  This means the tests are going to need revamping to work
> under NUnit GUI.  (Could this be a similar problem to what you have
> with NAnt?).

No, it works in both cases for me as well by now.  For the NUnit GUI it
might be some sort of setting (I use the "Run tests in a single separate
process" model).

> It appears that there is no way to change the current directory in
> NUnit GUI, so the tests would need modifications to have a consistent
> current directory while running.

> Comments/Suggestions?  I am new to the whole NUnit thing, so maybe there
> is an obvious solution I do not know about.

Just don't bother with them for now (emphasis on "for now").  You have a
way of passing the tests and so have I.

> FYI. Only 2 of the total 129 tests failed under the Visual NUnit plugin.
> TestGetEntryType in EventLogAppenderTest (looks like an expected
> SecurityException under Windows 7) and TestFullFix in
> RemotingAppednerTest.

The later might be a timing issue.  I have increased the delay between
logging a message and validating it has been written to the sink last
Wednesday - are you working on this version?  If so, then maybe the very
first wait-time must be made even bigger.

Stefan

Re: What to do with EventLogAppender on Vista and newer?

[Stefan Bodewig]

On 2011-09-11, Roy Chastain wrote:

>> (1) document that you need to create your event sources outside of
>> your application (usually during deployment) and (2) deal with the
>> SecurityException in a more graceful way (log something and disable
>> the appender, likely).

> +1 for each 1 and 2

OK, I'll see what I can come up with.

Stefan

Re: The state of RollingFileAppender

[Stefan Bodewig]

On 2011-09-12, Roy Chastain wrote:

> When I looked at this code a few years ago, I thought it was overly
> complicated and obtuse.  Since spending the day with it today, and
> discovering the invalid assumption, I stand by my original opinion.

I was afraid you'd say that when you volunteered to look into it.

So far I stayed away from RFA and concentrated on the other issues - and
never had any reason to read into RFA's code in the past.  We seem to
belong to the lucky few who haven't faced any of its internal issues.
But just from reading through the sevaral issues raised against it it
was clear to me that it must contain a multitude of problems that have
historically piled up.

> After looking at the 14 or so bug reports against RFA and remembering a
> few that I never submitted, I think RFA needs a major simplification via
> a rewrite to better handle gaps in the file names/numbers etc.

OK.

I think it would be good to push all of the RFA issues from 1.2.11 to
1.2 MAINTENANCE then and live with the fact that there will be known
issues with it in 1.2.11 - or do you expect to have a drop-in
replacement ready in a time frame of - say - a few weeks?

Unfortunately I still don't have a build environment for the "older"
frameworks (but am far from having given up on it) and this seems to be
the major hurdle for the 1.2.11 release right now.

> I am open to suggestions as to what features to add/delete from a
> rewritten RFA.  I know many people, including myself, have wanted a max
> number of files per time increment when rolled by size and time.

I think there is a JIRA issue (with patch IIRC) to that effect.

Stefan

Re: The state of RollingFileAppender

[Stefan Bodewig]

On 2011-09-12, Curt Arnold wrote:

> The rolling file appenders are the single greatest cause of recurring
> problems in log4j and all those problems have been inherited by
> log4net.

Quite possible.  RollingFileAppender is responsible for more than 10% of
all open log4net issues right now.

> There was a sandbox development of a MultiFileAppender (a file
> appender which could manage multiple open files) for log4j several
> years ago and it seemed like the use cases for the rolling file
> appenders could be addressed within the MultiFIleAppender.[1]

I can see how this would work with rolling if you are willing to accept
that the "primary" log file doesn't have a fixed name.  This doesn't mix
well with "tail -f some.log" (rolling right now doesn't either, but you
get a "file truncated" message or something to that effect).

MultiFileAppender addresses similar use cases as RollingFileAppender,
they sometimes overlap, but I don't think it could be a full
replacement.

> This link should catch most of the earlier discussion, but it has been a long 
> time since I've reviewed those messages:

> http://search.gmane.org/?query=MultiFileAppender&author=&group=gmane.comp.jakarta.log4j.devel&sort=revdate&DEFAULTOP=and&xP=multifileappender&xFILTERS=Gcomp.jakarta.log4j.devel---A--A

I promise to read through this, but (probably much) later. 8-)

Stefan

[1]
> The sandbox code can be checked out from
> http://svn.apache.org/repos/asf/logging/sandbox/log4j/multifile

RE: The state of RollingFileAppender

[Roy Chastain]

I do not expect to have a drop in replacement within few weeks.  My
guess is by end of November, if my current work load continues.  If not,
then sooner.

--
Roy Chastain



-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Monday, September 12, 2011 05:43
To: log4net-dev@logging.apache.org
Subject: Re: The state of RollingFileAppender

On 2011-09-12, Roy Chastain wrote:

> When I looked at this code a few years ago, I thought it was overly 
> complicated and obtuse.  Since spending the day with it today, and 
> discovering the invalid assumption, I stand by my original opinion.

I was afraid you'd say that when you volunteered to look into it.

So far I stayed away from RFA and concentrated on the other issues - and
never had any reason to read into RFA's code in the past.  We seem to
belong to the lucky few who haven't faced any of its internal issues.
But just from reading through the sevaral issues raised against it it
was clear to me that it must contain a multitude of problems that have
historically piled up.

> After looking at the 14 or so bug reports against RFA and remembering 
> a few that I never submitted, I think RFA needs a major simplification

> via a rewrite to better handle gaps in the file names/numbers etc.

OK.

I think it would be good to push all of the RFA issues from 1.2.11 to
1.2 MAINTENANCE then and live with the fact that there will be known
issues with it in 1.2.11 - or do you expect to have a drop-in
replacement ready in a time frame of - say - a few weeks?

Unfortunately I still don't have a build environment for the "older"
frameworks (but am far from having given up on it) and this seems to be
the major hurdle for the 1.2.11 release right now.

> I am open to suggestions as to what features to add/delete from a 
> rewritten RFA.  I know many people, including myself, have wanted a 
> max number of files per time increment when rolled by size and time.

I think there is a JIRA issue (with patch IIRC) to that effect.

Stefan

[jira] [Resolved] (LOG4NET-310) EventLogAppender's ActivateOptions throws SecurityException on Vista/Win2k3 and later when not run as administrator

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-310.


Resolution: Fixed

Test passes now (by using winlogon as EventSource) and error handling and 
documentation have been improved.

> EventLogAppender's ActivateOptions throws SecurityException on Vista/Win2k3 
> and later when not run as administrator
> ---
>
> Key: LOG4NET-310
> URL: https://issues.apache.org/jira/browse/LOG4NET-310
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.10
>Reporter: Stefan Bodewig
> Fix For: 1.2.11
>
>
> ActivateOptions uses EventLog.SourceExists which throws an exception of the 
> source hasn't been found in any of the logs the user was allowed to read and 
> there are others (in particular "Security") that the user is not allowed to 
> access.
> This is the reason of one of the unit test errors I reported in LOG4NET-301
> Even if the code catches the exception and assumes the source doesn't exist 
> this won't help as EventLog.CreateEventSource must not be called without 
> administrator privileges either.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (LOG4NET-129) EventLogAppender EventID parsing does not handle Active Properties properly

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-129.


Resolution: Fixed

fixed with svn revision 1169688

> EventLogAppender EventID parsing does not handle Active Properties properly
> ---
>
> Key: LOG4NET-129
> URL: https://issues.apache.org/jira/browse/LOG4NET-129
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
>Reporter: Michael Christensen
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: EventLogAppender.patch
>
>
> The EventLogAppender supports setting the EventID of the Event being logged 
> through Context Properties, as described here:
> http://www.mail-archive.com/log4net-user@logging.apache.org/msg02396.html
> However, since GlobalContext is inappropriate for storing the EventID (as it 
> is likely to be specific for any given individual call to Log) and 
> ThreadContext cannot be used reliably when running in the context of ASP.NET 
> (since ASP.NET might switch the request between threads during execution, as 
> outlined here: 
> http://piers7.blogspot.com/2005/12/log4net-context-problems-with-aspnet.html 
> ), it would be nice to be able to use an Active Property instead (which 
> could, for instance, delegate calls for the EventID to data stored in 
> HttpContext)
> Unfortunately, this does not work, since the EventLogAppender assumes that 
> the Context Property holding the EventID is either int or string. The 
> relevant code is found in EventLogAppender.cs, in the override protected void 
> Append(LoggingEvent loggingEvent) method:
> if (eventIDPropertyObj is int)
> {
>   eventID = (int)eventIDPropertyObj;
> }
> else
> {
>   string eventIDPropertyString = eventIDPropertyObj as string;
> }
> Any Active Property object will end up as null through the "as string" call, 
> and be ignored.
> Suggested naive fix: If eventIDPropertyString is non-null and of other type 
> than int or string, call ToString() on the object and TryParse as int. Or use 
> whatever handling of Active Properties found elsewhere in log4net.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (LOG4NET-214) EventLogAppender should also use config file to set EventId

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-214.


Resolution: Fixed

fixed with svn revision 1169694

> EventLogAppender should also use config file to set EventId
> ---
>
> Key: LOG4NET-214
> URL: https://issues.apache.org/jira/browse/LOG4NET-214
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.10
>Reporter: Vincent Guigui
> Fix For: 1.2.11
>
>
> It should be possible to set the EventId of the EventLogAppender using the 
> config file.
> example:
> IT would like to be able to setup EventId for certain error without having to 
> recompile the application:
>  type="log4net.Appender.EventLogAppender" >
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: What to do with EventLogAppender on Vista and newer?

[Stefan Bodewig]

On 2011-09-12, Stefan Bodewig wrote:

> On 2011-09-11, Roy Chastain wrote:

>>> (1) document that you need to create your event sources outside of
>>> your application (usually during deployment) and (2) deal with the
>>> SecurityException in a more graceful way (log something and disable
>>> the appender, likely).

>> +1 for each 1 and 2

> OK, I'll see what I can come up with.

(1) has already been done

and it doesn't even apply to Vista and newer only (what is new is that
you need local admin privs to even check whether an event source
exists).

I've improved the error logging that is going to happen and closed the
issue.

Stefan

[jira] [Resolved] (LOG4NET-38) EventLogAppender: Add support for setting the Category on Event Log messages.

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-38.
---

Resolution: Fixed

fixed with svn revision 1169705

> EventLogAppender: Add support for setting the Category on Event Log messages.
> -
>
> Key: LOG4NET-38
> URL: https://issues.apache.org/jira/browse/LOG4NET-38
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 1.2.9
>Reporter: Nicko Cadell
>Assignee: Ron Grabowski
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: add_category_for_EventLogAppender.patch
>
>
> The EventLog supports Categories for each message. A category is a short 
> integer.
> This could either be implemented as a fixed category value defined on the 
> appender at config time, or as a value read from the LoggingEvent properties. 
> The second option is more flexible as it allows the category to be specified 
> for each message, a default category could still be specified in the appender 
> configuration to allow for scenario 1 as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LOG4NET-258) Please add ability to dynamically set User and other Event Viewer properties using the Thread Contex or another means.

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LOG4NET-258:
---

Fix Version/s: (was: 1.2.11)
   1.2 Maintenance Release
  Summary: Please add ability to dynamically set User and other Event 
Viewer properties using the Thread Contex or another means.  (was: Event Log 
Appender or Thread Context property.  Please add ability to dynamically set 
Category, User, and other Event Viewer properties using the Thread Contex or 
another means.)

Category now works in 1.2.11 (not released, yet) thanks to LOG4NET-38

For "User" I need to defer to the next release for now.

> Please add ability to dynamically set User and other Event Viewer properties 
> using the Thread Contex or another means.
> --
>
> Key: LOG4NET-258
> URL: https://issues.apache.org/jira/browse/LOG4NET-258
> Project: Log4net
>  Issue Type: Wish
> Environment: Log4Net 1.2.10 on Windows Server 2008 server.  
>Reporter: Mary M Pankiw
>  Labels: EventLogAppender, properties
> Fix For: 1.2 Maintenance Release
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I am using the Event Log appender and need to be able to dynamically set the 
> event properties for each message.
> Currently I am using the following:
> Event Viewer Property   How I set it up 
> Date appender "conversionPattern" 
> node value as %d (w/ "layout" node type  = "log4net.Layout.PatternLayout")
> Source appender "applicationName" node 
> value * Would be nice if this could be set dynamically too...
> Type set based on type of log 
> Computer   picked up automatically 
> Event ID  Needed 2 things:  1.  appender 
> "conversionPattern" node value as%property{EventID} 2. Set thread context 
> property before call to write log, example: 
> log4net.ThreadContext.Properties["EventID"] = ;
> Category * HELP! :)
> User* HELP! :)
> * These are the ones I cannot find a way to set, I have scoured the internet 
> for examples, I would be thrilled (THRILLED) if these values could be set 
> like the EventID is set.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: The state of RollingFileAppender

[Roy Chastain]

There are many cases in which the current RFA code is broken.  Some of
the issues are design and some are code.  It can be made better, though
probably not perfect.  Any expected anomaly should be clearly
documented.  The interactions between various settings need to be better
documented.  In other words, set the users expectations.

I have read the history of MultiFileAppender.  It sounds rather
ambitious and, while a good idea, a drop in replacement for RFA is also
a good idea.  A new RFA would allow upgrade to new log4Net release to
gain stability without forcing a configuration change to a new appender.
I found the bug report (40066) on gaps to be of particular interest.  It
appears to be saying exactly what I seen on many occasions.

--
Roy Chastain




-Original Message-
From: Curt Arnold [mailto:curt.ar...@gmail.com] On Behalf Of Curt Arnold
Sent: Monday, September 12, 2011 00:40
To: Log4NET Dev
Subject: Re: The state of RollingFileAppender

The rolling file appenders are the single greatest cause of recurring
problems in log4j and all those problems have been inherited by log4net.


I don't think that the rolling file appenders are fixable. Any approach
that involves systematic renaming for files is not going to be robust.
Even a single rename operation can be expensive and the rollover time is
linear with the number of log files maintained which can result in
non-responsive apps as the log file history grows. log4j (and possibly
log4net) are stuck with retaining the known-to-be problematic rolling
file appenders for compatibility, but use of these appenders should be
discouraged. 

There was a sandbox development of a MultiFileAppender (a file appender
which could manage multiple open files) for log4j several years ago and
it seemed like the use cases for the rolling file appenders could be
addressed within the MultiFIleAppender. One of the weaknesses of the
existing RFA's were that they closed the previous log file before
opening the new log file which could land the appender in limbo if it
could not open a new log file and could not reopen the old log file.

This link should catch most of the earlier discussion, but it has been a
long time since I've reviewed those messages:

http://search.gmane.org/?query=MultiFileAppender&author=&group=gmane.com
p.jakarta.log4j.devel&sort=revdate&DEFAULTOP=and&xP=multifileappender&xF
ILTERS=Gcomp.jakarta.log4j.devel---A--A

The sandbox code can be checked out from
http://svn.apache.org/repos/asf/logging/sandbox/log4j/multifile

[jira] [Resolved] (LOG4NET-76) TextWriterAdapter is not thread safe

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-76.
---

Resolution: Fixed

The immediate multi-threading problem is fixed with svn revsion 1169711

I'll open a new issue to review whether we actually need ReusableStringWriter 
at al in a future release.

> TextWriterAdapter is not thread safe
> 
>
> Key: LOG4NET-76
> URL: https://issues.apache.org/jira/browse/LOG4NET-76
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows XP Pro sp2 with .Net 2
>Reporter: Bob Peterson
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: TextWriterAdapter.cs
>
>
> When logging using the XmlAppender, our company application can generate 
> overlapping appender calls.  TextWriterAppender is not thread safe.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (LOG4NET-312) Review whether ReusableStringWriter helps more than it harms

[Stefan Bodewig (JIRA)]

Review whether ReusableStringWriter helps more than it harms


 Key: LOG4NET-312
 URL: https://issues.apache.org/jira/browse/LOG4NET-312
 Project: Log4net
  Issue Type: Task
Affects Versions: 1.2.11
Reporter: Stefan Bodewig
 Fix For: 1.2 Maintenance Release


While fixing LOG4NET-76 I (like the original reporter) wondered whether 
properly locking the ReusableStringWriter instances used in PatternConverter 
and AppenderSkeleton really provides any benefit over just creating fresh 
StringWriter instances rather than reusing existing ones.

I came up with the idea that it may be better in memory pressured environments 
like phones thus I shied away from simply stop using ReusableStringWriter but 
that reason may simply be wrong (I don't have any real experience with compact 
framework and friends).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (LOG4NET-76) TextWriterAdapter is not thread safe

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig reopened LOG4NET-76:
---


Closed the wrong bug.

> TextWriterAdapter is not thread safe
> 
>
> Key: LOG4NET-76
> URL: https://issues.apache.org/jira/browse/LOG4NET-76
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows XP Pro sp2 with .Net 2
>Reporter: Bob Peterson
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: TextWriterAdapter.cs
>
>
> When logging using the XmlAppender, our company application can generate 
> overlapping appender calls.  TextWriterAppender is not thread safe.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LOG4NET-312) Review whether ReusableStringWriter helps more than it harms

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LOG4NET-312:
---

Description: 
While fixing LOG4NET-212 I (like the original reporter) wondered whether 
properly locking the ReusableStringWriter instances used in PatternConverter 
and AppenderSkeleton really provides any benefit over just creating fresh 
StringWriter instances rather than reusing existing ones.

I came up with the idea that it may be better in memory pressured environments 
like phones thus I shied away from simply stop using ReusableStringWriter but 
that reason may simply be wrong (I don't have any real experience with compact 
framework and friends).

  was:
While fixing LOG4NET-76 I (like the original reporter) wondered whether 
properly locking the ReusableStringWriter instances used in PatternConverter 
and AppenderSkeleton really provides any benefit over just creating fresh 
StringWriter instances rather than reusing existing ones.

I came up with the idea that it may be better in memory pressured environments 
like phones thus I shied away from simply stop using ReusableStringWriter but 
that reason may simply be wrong (I don't have any real experience with compact 
framework and friends).


> Review whether ReusableStringWriter helps more than it harms
> 
>
> Key: LOG4NET-312
> URL: https://issues.apache.org/jira/browse/LOG4NET-312
> Project: Log4net
>  Issue Type: Task
>Affects Versions: 1.2.11
>Reporter: Stefan Bodewig
> Fix For: 1.2 Maintenance Release
>
>
> While fixing LOG4NET-212 I (like the original reporter) wondered whether 
> properly locking the ReusableStringWriter instances used in PatternConverter 
> and AppenderSkeleton really provides any benefit over just creating fresh 
> StringWriter instances rather than reusing existing ones.
> I came up with the idea that it may be better in memory pressured 
> environments like phones thus I shied away from simply stop using 
> ReusableStringWriter but that reason may simply be wrong (I don't have any 
> real experience with compact framework and friends).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (LOG4NET-212) Threading bug in the PatternConverter.cs

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-212.


Resolution: Fixed

The immediate multi-threading problem is fixed with svn revsion 1169711

I've opened LOG4NET-312 to review whether we actually need ReusableStringWriter 
at all in a future release. 

> 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

RE: [jira] [Updated] (LOG4NET-312) Review whether ReusableStringWriter helps more than it harms

[Frank Watkins]

Please remove me from the mailing list.

Thanks,
 
Frank 
 
Product Verification Test
Medical Automation Systems
E-mail: fwatk...@rals.com
Business Phone #: 434-951-2926
Internal Phone: x3043
 
-Original Message-
From: Stefan Bodewig (JIRA) [mailto:j...@apache.org] 
Sent: Monday, September 12, 2011 8:45 AM
To: log4net-dev@logging.apache.org
Subject: [jira] [Updated] (LOG4NET-312) Review whether ReusableStringWriter 
helps more than it harms


 [ 
https://issues.apache.org/jira/browse/LOG4NET-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated LOG4NET-312:
---

Description: 
While fixing LOG4NET-212 I (like the original reporter) wondered whether 
properly locking the ReusableStringWriter instances used in PatternConverter 
and AppenderSkeleton really provides any benefit over just creating fresh 
StringWriter instances rather than reusing existing ones.

I came up with the idea that it may be better in memory pressured environments 
like phones thus I shied away from simply stop using ReusableStringWriter but 
that reason may simply be wrong (I don't have any real experience with compact 
framework and friends).

  was:
While fixing LOG4NET-76 I (like the original reporter) wondered whether 
properly locking the ReusableStringWriter instances used in PatternConverter 
and AppenderSkeleton really provides any benefit over just creating fresh 
StringWriter instances rather than reusing existing ones.

I came up with the idea that it may be better in memory pressured environments 
like phones thus I shied away from simply stop using ReusableStringWriter but 
that reason may simply be wrong (I don't have any real experience with compact 
framework and friends).


> Review whether ReusableStringWriter helps more than it harms
> 
>
> Key: LOG4NET-312
> URL: https://issues.apache.org/jira/browse/LOG4NET-312
> Project: Log4net
>  Issue Type: Task
>Affects Versions: 1.2.11
>Reporter: Stefan Bodewig
> Fix For: 1.2 Maintenance Release
>
>
> While fixing LOG4NET-212 I (like the original reporter) wondered whether 
> properly locking the ReusableStringWriter instances used in PatternConverter 
> and AppenderSkeleton really provides any benefit over just creating fresh 
> StringWriter instances rather than reusing existing ones.
> I came up with the idea that it may be better in memory pressured 
> environments like phones thus I shied away from simply stop using 
> ReusableStringWriter but that reason may simply be wrong (I don't have any 
> real experience with compact framework and friends).

--
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

[Dominik Guder]

Am 09.09.2011 05:52, schrieb Stefan Bodewig:

On 2011-09-08, Dominik Guder wrote:


using nant for retreiving svn revision to property svn.revision:
use svn log (repository access)




 
 
 





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



Hi Stefan, since we are using CC.Net as CI and build tool svn.exe is 
required on our buildserver. The only point we need assembly versioning. 
Another solution could be tortoisesvn.net subwcrev.exe. See

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
Using #svn and create a svn nant task is possible, but currently out of 
scope for me.


A minor change for this usecase I could think is to be able to use a 
Xml-String for xmlpeek instead of requiring a file. So the timeout could 
be removed and no additional file system access is needed.


So far Dominik

--
The answer to the great question of life,
the universe and everything is 42 (Douglas Adams)

Possible new code - DynamicPatternLayout

[Roy Chastain]

I have a new class that I implemented several years ago.  It provides a
DynamicPatternConverter.  Its primary purpose is to provide dynamic
headers and footers in logs.

Below is the description from the code
/// 
/// A flexible layout configurable with pattern string that
re-evaluates on each call.
/// 
/// 
/// This class is built on  and provides all the
/// features and capabilities of PatternLayout.  PatternLayout
is a 'static' class
/// in that its layout is done once at configuration time.  This
class will recreate
/// the layout on each reference.
/// One important difference between PatternLayout and
DynamicPatternLayout is the
/// treatment of the Header and Footer parameters in the
configuration.  The Header and Footer
/// parameters for DynamicPatternLayout must be syntactically in
the form of a PatternString,
/// but should not be marked as type log4net.Util.PatternString.
Doing so causes the
/// pattern to be staticly converted at configuration tiame and
causes DynamicPatternLayout
/// to perform the same as PatternLayout.
/// Please see  for complete
documentation.
/// 
/// 
///   
///   
/// 
/// 
/// 

I do not have test cases.  This code is available for inclusion in
log4Net if anyone feels that it is worth including.  I like it because I
can scan through a logfile and find out when it was closed and/or
opened.  (Append = true).  The entire module is 142 lines including
comments.

--
Roy Chastain

[jira] [Commented] (LOG4NET-76) TextWriterAdapter is not thread safe

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102708#comment-13102708
 ] 

Stefan Bodewig commented on LOG4NET-76:
---

The problem here is similar to LOG4NET-212 where an instance variable is 
modified by concurrent threads.

I'd say ProtectCloseTextWriter's Attach method is evil and TextwriterAdapter's 
m_writer should be readonly, but that would break too many APIs.

Other than with LOG4NET-212 I don't intend to keep the instance member and add 
synchronization but will rather remove the instance member completely.

I don't think the stack would really solve the problem, maybe make it surface 
less often.

> TextWriterAdapter is not thread safe
> 
>
> Key: LOG4NET-76
> URL: https://issues.apache.org/jira/browse/LOG4NET-76
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows XP Pro sp2 with .Net 2
>Reporter: Bob Peterson
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: TextWriterAdapter.cs
>
>
> When logging using the XmlAppender, our company application can generate 
> overlapping appender calls.  TextWriterAppender is not thread safe.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (LOG4NET-76) TextWriterAdapter is not thread safe

[Stefan Bodewig (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4NET-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig resolved LOG4NET-76.
---

Resolution: Fixed

fixed (really this issue this time, promised ;-) with svn revision 1169783

> TextWriterAdapter is not thread safe
> 
>
> Key: LOG4NET-76
> URL: https://issues.apache.org/jira/browse/LOG4NET-76
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows XP Pro sp2 with .Net 2
>Reporter: Bob Peterson
>Priority: Minor
> Fix For: 1.2.11
>
> Attachments: TextWriterAdapter.cs
>
>
> When logging using the XmlAppender, our company application can generate 
> overlapping appender calls.  TextWriterAppender is not thread safe.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LOG4NET-274) log4net doesn't log when running a .Net 4.0 Windows application built in Release mode

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102717#comment-13102717
 ] 

Stefan Bodewig commented on LOG4NET-274:


It likely really comes down to DLL load order and which one tries to use the 
logging system first.

If you can make sure you really get the very first access by using something 
like Application_Start in ASP.NET or OnStart in your ServiceBase subclass you 
should be able to only use the attribute in the assembly that contains the 
access (the web application or your service host assembly).

I'll update the docs to state that DLL load order may be different in DEBUG and 
RELEASE configurations and thus sometimes you need to search a little before 
you find the assembly that has to contain the attribute and that it may be 
different in different configurations.

> log4net doesn't log when running a .Net 4.0 Windows application built in 
> Release mode
> -
>
> Key: LOG4NET-274
> URL: https://issues.apache.org/jira/browse/LOG4NET-274
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.10
> Environment: Visual Studio 2010, C#, Windows 7
>Reporter: Deepu Thomas Palathara
>Priority: Blocker
> Fix For: 1.2.11
>
>
> I've a .Net 4.0 windows service application that uses log4net.
> Here's my log4net config.
> 
>   
> 
>   
> 
>   
>type="log4net.Appender.ColoredConsoleAppender">
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
>   
> 
> 
>   
> 
>   
>type="log4net.Appender.RollingFileAppender">
> 
> 
> 
> 
>   
> 
> 
> 
> 
>   
>   
> 
>   
> 
>   
>   
> 
> 
> 
>   
> 
> Logging works as expected when the service starts up while using the exe that 
> was built in debug mode (log files are created at the right file path), but 
> doesn't work when it is using the exe built in release mode.
> I've even tried using a recompiled log4net dll for .Net 4.0 following the 
> steps mentioned at this blog.. 
> http://tseonet.blogspot.com/2010/07/making-log4net-run-on-net-40.html. 
> That didn't work either. I was able to compile and run the service. But the 
> result was the same; no logs when using the exe build in release mode.
> Not sure what's going on. Cannot deploy the application built in debug mode 
> into production.
> Any help is greatly appreciated.

--
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

[Stefan Bodewig]

On 2011-09-12, Dominik Guder wrote:

> Am 09.09.2011 05:52, schrieb Stefan Bodewig:
>> 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.

> Hi Stefan, since we are using CC.Net as CI and build tool svn.exe is
> required on our buildserver. The only point we need assembly
> versioning. Another solution could be tortoisesvn.net
> subwcrev.exe. See
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
> Using #svn and create a svn nant task is possible, but currently out
> of scope for me.

Well, in our case I think - at least for now - I can simply limit it to
command line svn because it is going to be available on the machine that
builds the release binaries.

We want people to be able to build log4net from the source package
downloaded from our website.  In this case the extracted tree doesn't
have any svn information at all (in fact it doesn't correspond to a
revision number at all if local changes have been made) and the build
file has to cater for this.

I'll try to set up something that uses svn.exe to determine the
information I want and uses 0 as forth digit and an URL of "unknown
revision of " as fallback.

Stefan

Re: Possible new code - DynamicPatternLayout

[Stefan Bodewig]

On 2011-09-12, Roy Chastain wrote:

> I have a new class that I implemented several years ago.  It provides a
> DynamicPatternConverter.  Its primary purpose is to provide dynamic
> headers and footers in logs.

Aren't you paying a big price for this by also making the "normal"
pattern dynamic?  Maybe there is room for something in between where
only Header and Footer are dynamic?

> I do not have test cases.

But could add some ;-)

> This code is available for inclusion in log4Net if anyone feels that
> it is worth including.

I think it is (post 1.2.11).

Stefan

RE: Possible new code - DynamicPatternLayout

[Roy Chastain]

No price.  Only the header and footer as surfaced in the new class, so
the other properties resort back to their normal processing.  In
reality, the ConversionPattern for the log output is already dynamic,
but header and footer were not treated the same.

Ron G. actually gave me the idea of how to do this.

Do I run a "diff" against an empty file to produce the patch or is there
another method?

--
Roy Chastain




-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Monday, September 12, 2011 11:48
To: log4net-dev@logging.apache.org
Subject: Re: Possible new code - DynamicPatternLayout

On 2011-09-12, Roy Chastain wrote:

> I have a new class that I implemented several years ago.  It provides 
> a DynamicPatternConverter.  Its primary purpose is to provide dynamic 
> headers and footers in logs.

Aren't you paying a big price for this by also making the "normal"
pattern dynamic?  Maybe there is room for something in between where
only Header and Footer are dynamic?

> I do not have test cases.

But could add some ;-)

> This code is available for inclusion in log4Net if anyone feels that 
> it is worth including.

I think it is (post 1.2.11).

Stefan

[jira] [Commented] (LOG4NET-235) IP Address Pattern Converter

[Ron Grabowski (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103300#comment-13103300
 ] 

Ron Grabowski commented on LOG4NET-235:
---

I checked the 5 AspNet classes just now and they all have documentation

> IP Address Pattern Converter
> 
>
> Key: LOG4NET-235
> URL: https://issues.apache.org/jira/browse/LOG4NET-235
> Project: Log4net
>  Issue Type: New Feature
>  Components: Other
>Affects Versions: 1.2.10
>Reporter: Adam Davies
>Priority: Trivial
> Fix For: 1.2 Maintenance Release
>
> Attachments: log4net - IP Address.zip
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Created AspNetIPAddressPatternConverter to provide the client IP Address.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Possible new code - DynamicPatternLayout

[Stefan Bodewig]

On 2011-09-12, Roy Chastain wrote:

> No price.  Only the header and footer as surfaced in the new class, so
> the other properties resort back to their normal processing.  In
> reality, the ConversionPattern for the log output is already dynamic,
> but header and footer were not treated the same.

Oh, so I misunderstood the nature of "dynamic".  I thought you'd be
re-parsing the pattern string for each call to Format.

> Do I run a "diff" against an empty file to produce the patch or is there
> another method?

GNU diff has a "-N" option to treat missing files that way.  If you only
have a new file and don't touch any of the existing other files then
simply attaching the file may be easier.

Stefan

[jira] [Commented] (LOG4NET-235) IP Address Pattern Converter

[Stefan Bodewig (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103315#comment-13103315
 ] 

Stefan Bodewig commented on LOG4NET-235:


I think we also need class-level docs in PatternLayout as well as a few lines 
for the website (at least 
http://logging.apache.org/log4net/release/manual/introduction.html#layouts )

Unless you beat me to it I'll copy over your docs sometime later.

> IP Address Pattern Converter
> 
>
> Key: LOG4NET-235
> URL: https://issues.apache.org/jira/browse/LOG4NET-235
> Project: Log4net
>  Issue Type: New Feature
>  Components: Other
>Affects Versions: 1.2.10
>Reporter: Adam Davies
>Priority: Trivial
> Fix For: 1.2 Maintenance Release
>
> Attachments: log4net - IP Address.zip
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Created AspNetIPAddressPatternConverter to provide the client IP Address.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira