[jira] [Comment Edited] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig edited comment on LOG4NET-415 at 1/13/14 3:19 PM:
-

Sorry for not responding for so long - and in addition I don't really have my 
brain with me right now, so I may be suggesting stupid things.

* without Jose Luis' changes SyslogAppender had guaranteed delivery - if we add 
an option to use non-blocking sockets we need to make this change explicit (or 
rather state what the choice of the parameter entails).  It is quite possible 
people using a syslog appender don't  actually know they are using UDP under 
the covers.

* doing things asynchronously requires some extra coding - you need to "fix" 
thread-local state that may contribute to the log message.  I think there is 
some kind of AsyncAppender similar to BufferingForwardingAppender inside this 
JIRA (and if there isn't, then we still should provide one).  I'd prefer a 
generic async appender (using ,NET 2.0 compatible code if possible) over 
appender specific async solutions.

Just did a quick search: LOG4NET-190, LOG4NET-201, LOG4NET-407 and apparently 
we already have got some sort of AsyncAppender inside the examples, oops.


was (Author: bodewig):
Sorry for not responding for so long - and in addition I don't really have my 
brain with me right now, so I may be suggesting stupid things.

* without Jose Luis' changes SyslogAppender had guaranteed delivery - if we add 
an option to use non-blocking sockets we need to make this change explicit (or 
rather state what the choice of the parameter entails).  It is quite possible 
people using a syslog appender don't  actually know they are using UDP under 
the covers.

* doing things asynchronously requires some extra coding - you need to "fix" 
thread-local state that may contribute to the log message.  I think there is 
some kind of AsyncAppender similar to BufferingForwardingAppender inside this 
JIRA (and if there isn't, then we still should provide one).  I'd prefer a 
generic async appender (using ,NET 2.0 compatible code if possible) over 
appender specific async solutions.

> RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
> --
>
> Key: LOG4NET-415
> URL: https://issues.apache.org/jira/browse/LOG4NET-415
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.13
> Environment: Any Windows environment
>Reporter: Jose Luis Pedrosa
>  Labels: RemoteSyslogAppender
> Attachments: LOG4NET-415.patch, MessageLostTest.cs, 
> MessageLostTest.cs, MessageLostTestAsync.cs, RemoteSyslogNonBlockingv2.patch
>
>
> Sending UDP packages may block for some time in specific circumstances:
> 1) Next hop in network level 3 can't be resolved by ARP.
> 2) Datagram size exceeds FastSendDatagramThreshold configured size.
> When sending packets bigger than FastSendDatagramThreshold, the OS waits 
> until the packet is actually sent, if the If the syslog (or the next hop to 
> reach the syslog) is in the same VLAN/Subnet the OS tries to resolve by ARP 
> the Ip of the configured syslog, this may take up to 3 seconds, slowing down 
> the whole application, which in some cases can lead to outages (timeouts, DB 
> locks...).
> Also the fact that each carriage return generates the headers of the packet 
> again, that can lead to a significant overhead in some scenarios, for 
> instance when loggign HTTP requests to a remote syslog, every header will go 
> in a different message. Also some logging may require characters that are now 
> skipped in patch:  https://issues.apache.org/jira/browse/LOG4NET-370
> I'm adding a patch that
> 1) Moves the use of UDPClient to Non blocking sockets, which eliminates the 
> blocking. 
> 2) Adds a configuration field to decide if you want Strict RFC Behaviour or 
> not (with default Strict).
> Please your feedback, thanks in advance
> Jose Luis



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-415:


Sorry for not responding for so long - and in addition I don't really have my 
brain with me right now, so I may be suggesting stupid things.

* without Jose Luis' changes SyslogAppender had guaranteed delivery - if we add 
an option to use non-blocking sockets we need to make this change explicit (or 
rather state what the choice of the parameter entails).  It is quite possible 
people using a syslog appender don't  actually know they are using UDP under 
the covers.

* doing things asynchronously requires some extra coding - you need to "fix" 
thread-local state that may contribute to the log message.  I think there is 
some kind of AsyncAppender similar to BufferingForwardingAppender inside this 
JIRA (and if there isn't, then we still should provide one).  I'd prefer a 
generic async appender (using ,NET 2.0 compatible code if possible) over 
appender specific async solutions.

> RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
> --
>
> Key: LOG4NET-415
> URL: https://issues.apache.org/jira/browse/LOG4NET-415
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.13
> Environment: Any Windows environment
>Reporter: Jose Luis Pedrosa
>  Labels: RemoteSyslogAppender
> Attachments: LOG4NET-415.patch, MessageLostTest.cs, 
> MessageLostTest.cs, MessageLostTestAsync.cs, RemoteSyslogNonBlockingv2.patch
>
>
> Sending UDP packages may block for some time in specific circumstances:
> 1) Next hop in network level 3 can't be resolved by ARP.
> 2) Datagram size exceeds FastSendDatagramThreshold configured size.
> When sending packets bigger than FastSendDatagramThreshold, the OS waits 
> until the packet is actually sent, if the If the syslog (or the next hop to 
> reach the syslog) is in the same VLAN/Subnet the OS tries to resolve by ARP 
> the Ip of the configured syslog, this may take up to 3 seconds, slowing down 
> the whole application, which in some cases can lead to outages (timeouts, DB 
> locks...).
> Also the fact that each carriage return generates the headers of the packet 
> again, that can lead to a significant overhead in some scenarios, for 
> instance when loggign HTTP requests to a remote syslog, every header will go 
> in a different message. Also some logging may require characters that are now 
> skipped in patch:  https://issues.apache.org/jira/browse/LOG4NET-370
> I'm adding a patch that
> 1) Moves the use of UDPClient to Non blocking sockets, which eliminates the 
> blocking. 
> 2) Adds a configuration field to decide if you want Strict RFC Behaviour or 
> not (with default Strict).
> Please your feedback, thanks in advance
> Jose Luis



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (LOG4NET-415) RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-415:


I'm not a syslog expert, far from it.  I'm afraid if we start talking about 
RFC5424 then we'd signal way more support than we actually offer (structured 
data, TLS, maybe even TCP based transport - I know the latter are technically 
different RFCs).

As for your patch, I'm not sure what the non-strict mode would offer - does it 
work for RFC5424 compliant targets?

I'm more than happy with using non-blocking sockets, BTW, will only need to 
look up the used APIs to verify they are available for NETCF as well.

> RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
> --
>
> Key: LOG4NET-415
> URL: https://issues.apache.org/jira/browse/LOG4NET-415
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.13
> Environment: Any Windows environment
>Reporter: Jose Luis Pedrosa
>  Labels: RemoteSyslogAppender
> Attachments: LOG4NET-415.patch
>
>
> Sending UDP packages may block for some time in specific circumstances:
> 1) Next hop in network level 3 can't be resolved by ARP.
> 2) Datagram size exceeds FastSendDatagramThreshold configured size.
> When sending packets bigger than FastSendDatagramThreshold, the OS waits 
> until the packet is actually sent, if the If the syslog (or the next hop to 
> reach the syslog) is in the same VLAN/Subnet the OS tries to resolve by ARP 
> the Ip of the configured syslog, this may take up to 3 seconds, slowing down 
> the whole application, which in some cases can lead to outages (timeouts, DB 
> locks...).
> Also the fact that each carriage return generates the headers of the packet 
> again, that can lead to a significant overhead in some scenarios, for 
> instance when loggign HTTP requests to a remote syslog, every header will go 
> in a different message. Also some logging may require characters that are now 
> skipped in patch:  https://issues.apache.org/jira/browse/LOG4NET-370
> I'm adding a patch that
> 1) Moves the use of UDPClient to Non blocking sockets, which eliminates the 
> blocking. 
> 2) Adds a configuration field to decide if you want Strict RFC Behaviour or 
> not (with default Strict).
> Please your feedback, thanks in advance
> Jose Luis



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: State of reshuffling in trunk

[Stefan Bodewig]

On 2013-12-02, Dominik Psenner wrote:

> Looks like I found a typo:

quite possible, I tried to fix the main solutions by hand, so please go
ahead and fix it.  Also I think migrating the example and extension
solutions to VS2012 would be better than leavin in broken solutions.

> And maybe the svn-ignore properties should be fixed to ignore folders
> like "obj" and similars.

I thought that was the case already, if not, feel free to add them.

Thanks

Stefan

State of reshuffling in trunk

[Stefan Bodewig]

Hi,

by now all source files are below src in trunk, we have four different
NAnt build files in the root for the main build, tests, extensions and
examples and Jenkins is set up to build all of them.

I didn't manage to build the C++ example, looks as if I never installed
the compiler.  I haven't installed any version of VS so far so the
solution and project files are probably all borked - help welcome.

Next up will be the documentation stuff - i'll seriously try to replace
ndoc with sandcastle, who knows, maybe we'll even get output that
doesn't look strange when served by the website.

The final step for me will be adapting the release bundling targets.

Stefan

[jira] [Commented] (LOG4NET-411) Release 1.2.13.0 is no longer compatible with .Net 2.0

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-411:


Yes, the change was intentional in order to fix LOG4NET-404.

As long as you use the 2.0 version when you need to support 2.0 things should 
work.


> Release 1.2.13.0 is no longer compatible with .Net 2.0
> --
>
> Key: LOG4NET-411
> URL: https://issues.apache.org/jira/browse/LOG4NET-411
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.13
>Reporter: Jørn Frode Jensen
>  Labels: build
>
> According to Reflector output for the 3.5 client profile version of log4net, 
> there is a reference from log4net.dll to System.Core version 3.5. 
> Version 1.2.12.0 worked with .Net 2.0, but failed on dynamic methods 
> ([LOG4NET-393]). This was fixed in 1.2.13.0, but this version now fails with 
> .Net 2.0.
> Is this as designed?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-411) Release 1.2.13.0 is no longer compatible with .Net 2.0

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-411:


The 3.5 CP assembly is not compatible with .NET 2.0, use the 2.0 assembly when 
targeting 2.0 - ist there any problem with it?

> Release 1.2.13.0 is no longer compatible with .Net 2.0
> --
>
> Key: LOG4NET-411
> URL: https://issues.apache.org/jira/browse/LOG4NET-411
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.13
>Reporter: Jørn Frode Jensen
>  Labels: build
>
> According to Reflector output for the 3.5 client profile version of log4net, 
> there is a reference from log4net.dll to System.Core version 3.5. 
> Version 1.2.12.0 worked with .Net 2.0, but failed on dynamic methods 
> ([LOG4NET-393]). This was fixed in 1.2.13.0, but this version now fails with 
> .Net 2.0.
> Is this as designed?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-410) Please delete old releases from mirroring system

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-410.


Resolution: Fixed

removed the 1.2.12 release which became "old" less then a week ago :-)

When I cut releases I leave the new release and its predecessor alive for a few 
days, obviously for too long.  Thanks for the reminder.

> Please delete old releases from mirroring system
> 
>
> Key: LOG4NET-410
> URL: https://issues.apache.org/jira/browse/LOG4NET-410
> Project: Log4net
>  Issue Type: Bug
> Environment: http://www.apache.org/dist/logging/log4net/binaries/
>Reporter: Sebb
>
> To reduce the load on the ASF mirrors, projects are required to delete old 
> releases [1]
> Please can you remove all non-current releases?
> Thanks!
> [Note that older releases are always available from the ASF archive server]
> [1] http://www.apache.org/dev/release.html#when-to-archive



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-281) Insufficient Granularity on Log methods in ILog

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-281:


bq. When and under which conditions is adding new methods without changing the 
old ones a breaking change?

You break custom implementations of {{ILog}} - not sure anybody outside of 
log4net does so, but when we add methods we'd break it.  Since we are already 
willing to break BWC with 1.3.x this shouldn't be a problem.

As for extensions methods: we still are at .NET 2.0 with 1.3.x - if this wasn't 
the case we could easily strip {{ILog}} down to what {{log4net.Core.ILogger}} 
provides and implement all the other methods as extension methods (which might 
be a bit too radical).

> Insufficient Granularity on Log methods in ILog
> ---
>
> Key: LOG4NET-281
> URL: https://issues.apache.org/jira/browse/LOG4NET-281
> Project: Log4net
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.10
> Environment: All Environments
>Reporter: Zev
> Fix For: 1.3.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> The driver for this change is that we are unable to log certain event types 
> from the ILog object. While we can use the Logger object, it is easier to 
> have them here.
> updated code:
> ILog.cs
> //start new
> void Emergency(object message);
> void Emergency(object message, Exception e);
> void Alert(object message);
> void Alert(object message, Exception e);
> void Critical(object message);
> void Critical(object message, Exception e);
> void Notice(object message);
> void Notice(object message, Exception e);
> //end new
> LogImpl.cs (in ReloadLevels)
> //start new
> m_levelEmergency = levelMap.LookupWithDefault(Level.Emergency);
> m_levelAlert = levelMap.LookupWithDefault(Level.Alert);
> m_levelCritical = levelMap.LookupWithDefault(Level.Critical);
> m_levelNotice = levelMap.LookupWithDefault(Level.Notice);
> //end new
> methods:
> //start new
> virtual public void Emergency(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelEmergency, message, null);
> }
> virtual public void Emergency(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelEmergency, message, 
> exception);
> }
> virtual public void Alert(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelAlert, message, null);
> }
> virtual public void Alert(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelAlert, message, exception);
> }
> virtual public void Critical(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelCritical, message, null);
> }
> virtual public void Critical(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelCritical, message, 
> exception);
> }
> virtual public void Notice(object message)
> {
> Logger.Log(ThisDeclaringType, m_levelNotice, message, null);
> }
> virtual public void Notice(object message, Exception exception)
> {
> Logger.Log(ThisDeclaringType, m_levelNotice, message, exception);
> }
> //end new
> private fields:
> //start new
> private Level m_levelEmergency;
> private Level m_levelAlert;
> private Level m_levelCritical;
> private Level m_levelNotice;
> //end new



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-351) Blue tooth is not connecting to the selected device after pairing.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-351.


   Resolution: Invalid
Fix Version/s: (was: 1.3.0)

> Blue tooth is not connecting to the selected device after pairing.
> --
>
> Key: LOG4NET-351
> URL: https://issues.apache.org/jira/browse/LOG4NET-351
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.3.0
> Environment: Android version2.3.6, Blue Tooth version 2.0, samsung S3
>Reporter: karthikreddy.p
>  Labels: patch
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> 1.Select Menu
> 2.Go to tools and click on Blue Tooth
> 3. Power on Blue Tooth
> 4. Click on search devices
> 5. Select the available device.
> 6. Click on the desired device.
> 7. Click on Ok Button.
> 8.Send a file to the connected device.
> Expected Results:
> Selected file should be transferred successfully to the connected device.
> Actual Results:
> Error message is displayed as " File transfer is failed".



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-351) Blue tooth is not connecting to the selected device after pairing.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reopened LOG4NET-351:


  Assignee: (was: Dominik Psenner)

sorry, need to reopen to remove the "fix version" field.

> Blue tooth is not connecting to the selected device after pairing.
> --
>
> Key: LOG4NET-351
> URL: https://issues.apache.org/jira/browse/LOG4NET-351
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.3.0
> Environment: Android version2.3.6, Blue Tooth version 2.0, samsung S3
>Reporter: karthikreddy.p
>  Labels: patch
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> 1.Select Menu
> 2.Go to tools and click on Blue Tooth
> 3. Power on Blue Tooth
> 4. Click on search devices
> 5. Select the available device.
> 6. Click on the desired device.
> 7. Click on Ok Button.
> 8.Send a file to the connected device.
> Expected Results:
> Selected file should be transferred successfully to the connected device.
> Actual Results:
> Error message is displayed as " File transfer is failed".



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-409) Generics added to the Logger

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-409:


Ben, please forgive if I sounded as if I wanted to school you, far from it.  
For one part I was trying to explain why you didn't find generics in the 
current code base and for the other I wanted to understand your ideas better.

For the first part, log4net still largely is the same codebase that was started 
with .NET 1.1 being bleeding edge.  To be honest we lack the volunteer 
coder-power required to rewrite what is there, even if a modernized codebase 
was easier to maintain.

In a usecase like yours I'd probably use a single logger and custom filters - 
i.e. the filters would be supposed to select the correct appender based on the 
object I was logging.  This is a different approach and not necessarily one 
that was superior.

For my personal taste ILog is already too big so I agree with Dominik that a 
functionality like your generic logger might be better suited for a custom 
logger interface that delegates to a log4net ILog.  We have examples for such 
custom loggers in the extensions subfolder of the source tree.

> Generics added to the Logger
> 
>
> Key: LOG4NET-409
> URL: https://issues.apache.org/jira/browse/LOG4NET-409
> Project: Log4net
>  Issue Type: Wish
>  Components: Core
>Affects Versions: 1.3.0
>Reporter: Ben
>  Labels: features
>
> Maybe this has been suggested before - if so sorry (I did do a search for it).
> I am fairly new to log4net and when I am using it, I was surprised to see 
> that the log methods take an object as a parameter.  Of course this made 
> sense after I found out that Object Renderers can be made to parse any type 
> of object.  I did wonder why Generics was not used.
> If I have an Object Renderer that knows how to log Orange objects then I 
> don't want to accidentally pass it an Apple object (or any other type of 
> object).
> So using Generics I would set up my logger as follows:
> private ILog myOrangeLogger = 
> LogManager.GetLogger("OrangeLogger");
> I have just made a special type of logger that can log oranges.  Instead of 
> accepting parameters of type object it accepts only strings and Oranges.  
> Behind the scenes the method
> LogManager.GetLogger(string name) 
> would return a logger of type ILog.
> The ILog interface would have methods on it like:
> ILog.Warn(string message);
> ILog.Warn(T message);
> ILog.Warn(string message, Exception ex);
> ILog.Warn(T message, Exception ex);
> but would NOT have the method:
> ILog.Warn(object message);
> So now if I tried to pass it an Apple object I would get a compile error 
> rather than the default behaviour for a logger which has been given an object 
> that has no special renderer (in fact I probably wouldn't even realise until 
> I went to look at the log files right?).  This would be much better and would 
> help to save me from embarrassing myself in front of my customers.
> This could be added in addition to the standard loggers which would still be 
> returned in the normal way using:
> LogManager.GetLogger(string name);
> If this has not already been suggested then I hope you like this idea.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-406) Log4Net breaks the Microsoft naming rules for namespaces

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-406:


I'm really on the fence here, but the guideline says 

bq. If your brand employs nontraditional casing, you should follow the casing 
defined by your brand, even if it deviates from normal namespace casing

The official brand is "Apache log4net" with an all lowercase log4net.

> Log4Net breaks the Microsoft naming rules for namespaces
> 
>
> Key: LOG4NET-406
> URL: https://issues.apache.org/jira/browse/LOG4NET-406
> Project: Log4net
>  Issue Type: Improvement
>  Components: Appenders, Core
>Affects Versions: 1.2.9, 1.2.10, 1.2.11, 1.2.12, 1.2.13, 1.3.0, 1.2 
> Maintenance Release, 3.5, 4.0
> Environment: Windows 7, .Net 4.0
>Reporter: Michael Goldfinger
>Priority: Trivial
> Fix For: 1.3.0
>
>
> The log4net namespace violates the naming convention for namespaces in .Net.
> http://msdn.microsoft.com/en-us/library/vstudio/ms229026(v=vs.100).aspx
> As stated Pacal casing should be used: "Do use Pascal casing, and separate 
> namespace components with periods (for example, Microsoft.Office.PowerPoint)"



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-409) Generics added to the Logger

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-409:


Well, the major reason why you don't find generics in the codebase is that 
log4net is so old and so strict with backwards compatibility that generics had 
to be ruled out.  The log4net 1.2.13 release cut just this week ships with 
assemblies compiled for .NET 1.1 and is supposed to even compile on 1.0.  This 
no longer is an issue with the current svn trunk which will become 1.3.0 one 
day and will require .NET 2.0 as a minimum.

Leaving this aside, I must admit that you are describing a usecase I've never 
encountered so far.  I've never had any reason to restrict what types I wanted 
to send to my logger.  In fact I don't need the ability to log anything but 
strings (including strings created with format and a bunch of non-string 
parameters) or exceptions most of the time.  I tend to have exactly one logger 
per class and probably don't know what I'll be logging when I define the 
corresponding static field.

Could you please explain the real-world scenario where you'd use them and what 
you'd use them for?  I'm sure I must be missing an important point.

> Generics added to the Logger
> 
>
> Key: LOG4NET-409
> URL: https://issues.apache.org/jira/browse/LOG4NET-409
> Project: Log4net
>  Issue Type: Wish
>  Components: Core
>Affects Versions: 1.3.0
>Reporter: Ben
>  Labels: features
>
> Maybe this has been suggested before - if so sorry (I did do a search for it).
> I am fairly new to log4net and when I am using it, I was surprised to see 
> that the log methods take an object as a parameter.  Of course this made 
> sense after I found out that Object Renderers can be made to parse any type 
> of object.  I did wonder why Generics was not used.
> If I have an Object Renderer that knows how to log Orange objects then I 
> don't want to accidentally pass it an Apple object (or any other type of 
> object).
> So using Generics I would set up my logger as follows:
> private ILog myOrangeLogger = 
> LogManager.GetLogger("OrangeLogger");
> I have just made a special type of logger that can log oranges.  Instead of 
> accepting parameters of type object it accepts only strings and Oranges.  
> Behind the scenes the method
> LogManager.GetLogger(string name) 
> would return a logger of type ILog.
> The ILog interface would have methods on it like:
> ILog.Warn(string message);
> ILog.Warn(T message);
> ILog.Warn(string message, Exception ex);
> ILog.Warn(T message, Exception ex);
> but would NOT have the method:
> ILog.Warn(object message);
> So now if I tried to pass it an Apple object I would get a compile error 
> rather than the default behaviour for a logger which has been given an object 
> that has no special renderer (in fact I probably wouldn't even realise until 
> I went to look at the log files right?).  This would be much better and would 
> help to save me from embarrassing myself in front of my customers.
> This could be added in addition to the standard loggers which would still be 
> returned in the normal way using:
> LogManager.GetLogger(string name);
> If this has not already been suggested then I hope you like this idea.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-408) Correction on InterProcessLock

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-408.


Resolution: Fixed

svn revision 1544744.

> Correction on InterProcessLock
> --
>
> Key: LOG4NET-408
> URL: https://issues.apache.org/jira/browse/LOG4NET-408
> Project: Log4net
>  Issue Type: Bug
>    Reporter: Stefan Bodewig
> Fix For: 1.3.0
>
>
> This is github pull request 6: https://github.com/apache/log4net/pull/6
> {quote}
> This correction enables opening a new file without causing all the 
> AcquireLock blocking with AbandonedMutexException caused by incorrect state 
> on ReleaseLock, namely m_mutexClosed.
> The bug was found using InterProcessLockwith RollingFileAppender with date 
> pattern on file name, at midnight the new file is opened and all logging 
> becomes blocked at InterProcessLock.AcquireLock on m_mutex.WaitOne.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-187) Add a Trace level with isTraceEnabled.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-187.


Resolution: Fixed

added with svn revision 1544675

> Add a Trace level with isTraceEnabled.
> --
>
> Key: LOG4NET-187
> URL: https://issues.apache.org/jira/browse/LOG4NET-187
> Project: Log4net
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.10
>Reporter: Mihran Shahinian
> Fix For: 1.3.0
>
> Attachments: patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I am adding a simple patch for a trace level logging.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (LOG4NET-408) Correction on InterProcessLock

[Stefan Bodewig (JIRA)]

Stefan Bodewig created LOG4NET-408:
--

 Summary: Correction on InterProcessLock
 Key: LOG4NET-408
 URL: https://issues.apache.org/jira/browse/LOG4NET-408
 Project: Log4net
  Issue Type: Bug
Reporter: Stefan Bodewig
 Fix For: 1.3.0


This is github pull request 6: https://github.com/apache/log4net/pull/6

{quote}
This correction enables opening a new file without causing all the AcquireLock 
blocking with AbandonedMutexException caused by incorrect state on ReleaseLock, 
namely m_mutexClosed.

The bug was found using InterProcessLockwith RollingFileAppender with date 
pattern on file name, at midnight the new file is opened and all logging 
becomes blocked at InterProcessLock.AcquireLock on m_mutex.WaitOne.
{quote}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Jenkins build is back to normal : log4net-trunk-tests #20

[Stefan Bodewig]

On 2013-11-22, Dominik Psenner wrote:

> Finally. :-)

Yeah.  Jenkins has now two Windows slaves and the new one was added to
the roster before Nant was installed.

Stefan

[ANN] Apache log4net 1.2.13 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache log4net team is pleased to announce the release of Apache
log4net 1.2.13.  The release is available for download at

http://logging.apache.org/log4net/download.html

The Apache log4net library is a tool to help the programmer output log
statements to a variety of output targets.  log4net is a port of the
excellent Apache log4j framework to the Microsoft(R) .NET runtime.

The log4net 1.2.13 release fixes a problem with stack frames of dynamic
methods in .NET 4.0 as well as a few regressions introduced with 1.2.12.
The assemblies built for .NET 3.5 (CP) now also contain the ILog
extensions methods.

See the release-notes at

http://logging.apache.org/log4net/release/release-notes.html

for a full list of changes.

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on log4net, including instructions on how to
submit bug reports, patches, or suggestions for improvement, see the
Apache log4net website:

http://logging.apache.org/log4net/

Stefan Bodewig on behalf of the log4net community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlKOEzYACgkQohFa4V9ri3I2TQCfbT61K9GkBtTBaKctxMajjtgq
lNQAoM2VqdGr9o0HhPpl8zRsg1wMXCRK
=XawW
-END PGP SIGNATURE-

[jira] [Updated] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-376:
---

Fix Version/s: 1.2.13

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
> Fix For: 1.2.13, 1.3.0
>
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-376:
---

Fix Version/s: (was: 1.2.13)

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
> Fix For: 1.2.13, 1.3.0
>
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

KEYS in dist (was Re: [VOTE] Release Log4Net 1.2.13 based on RC3)

[Stefan Bodewig]

On 2013-11-21, Christian Grobmeier wrote:

> On 21 Nov 2013, at 8:15, Stefan Bodewig wrote:

>> On 2013-11-21, Christian Grobmeier wrote:

>>> One no blocker which I just saw: the KEYS file is included in the
>>> dist. Shouldn't it be left out?

>> I think we've always done it that way in log4net and I know Ant has been
>> doing so since 2000 - what's wrong with it?

> when somebody downloads it and opens the zip, it is tempting to
> validate the package against the included KEYS file. But if somebody
> could manipulate the content of the package, he also could manipulate
> the KEYS file.  For that reason the KEYS file should be on a different
> location. This is the case, that's why I meant it's not critical. It
> is on the other hand tempting to take the included one… nitpickery!
> Thanks for pushing out the release!

If this "somebody" downloaded the signature from the ASF and not from a
mirror then the signature will not work if the zip has been modified, no
matter which KEYS file it contains.  Unless you think the attacker has
modifie the signature, but then the KEYS file in the dist area would be
as vulnerable as that.

Stefan

[RESULT] Release Log4Net 1.2.13 based on RC3

[Stefan Bodewig]

So I count three +1s by Dominik, Christian and myself with no other
votes.

As usual I'll publish the distro and give the mirrors some time to catch
up before sending out the announcement and updating the site.

Stefan

Re: [VOTE] Release Log4Net 1.2.13 based on RC3

[Stefan Bodewig]

On 2013-11-21, Christian Grobmeier wrote:

> +1

> checked formalities, but didn't interpret the content b/c lack of
> windows :-)

thanks.

> One no blocker which I just saw: the KEYS file is included in the
> dist. Shouldn't it be left out?

I think we've always done it that way in log4net and I know Ant has been
doing so since 2000 - what's wrong with it?

Stefan

[VOTE] Release Log4Net 1.2.13 based on RC3

[Stefan Bodewig]

Hi all,

three times is a charm. :-)

Changes over RC2 is a packaging change (the 3.5 assemblies now contain
the ILogExtensions) and two bug fixes.

log4net 1.2.13 RC3 is available for review here:
  https://dist.apache.org/repos/dist/dev/logging/log4net
  (revision 3550)

Details of changes since 1.2.12 are in the release notes:
  http://logging.apache.org/log4net/log4net-1.2.13/release/release-notes.html

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
  https://svn.apache.org/repos/asf/logging/log4net/tags/1.2.13RC3
  (revision 1542676)

Site:
  http://logging.apache.org/log4net/log4net-1.2.13/

  (this is revision 887035 of
  
https://svn.apache.org/repos/infra/websites/production/logging/content/log4net/log4net-1.2.13)

RAT Report:
  http://logging.apache.org/log4net/log4net-1.2.13/rat-report.html

Votes, please.  This vote will close in 72 hours, 0530 GMT 21-Nov
2013

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

Stefan

[jira] [Commented] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-376:


brought back the big lock with svn revision 1542664

I'll keep this ticket open as I'd like to look into different approaches to 
solve it in 1.3.0.

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
> Fix For: 1.2.13, 1.3.0
>
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-376:
---

Fix Version/s: 1.3.0
   1.2.13

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
> Fix For: 1.2.13, 1.3.0
>
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [jira] [Commented] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig]

On 2013-11-16, Dominik Psenner wrote:

> Strange. Would you please do a safety check whether other things were
> reverted too?

the other changes made in that revision look legit to me.

Sorry for not cathcing it when the commit was made.

Stefan

[jira] [Commented] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-376:


I'm afraid svn revision 1486883 
http://svn.apache.org/viewvc/logging/log4net/trunk/src/log4net/DateFormatter/AbsoluteTimeDateFormatter.cs?r1=1483378&r2=1486883
 has reverted the locking that Dominik had introduced.  I'll bring them back 
for 1.2.13 and also verify we don't access the dictionary outside of a lock.

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: LOG4NET-405 (was Re: [VOTE] Release Log4Net 1.2.13 based on RC2)

[Stefan Bodewig]

On 2013-11-14, Dominik Psenner wrote:

>> I'm not sure whether setting the encoding to UTF8 triggers some sort of
>> different handling inside of the framweork's SMTP code even if the test
>> was pure ASCII.  If it doesn't, then I'm fine with UTF8.

> and checking a few of my Gmail's mails it seems they default to UTF8. I've
> just spammed test messages, this is the code:

OK, looks as if the main difference was UTF8 yields base64 encoding
while ASCII yields quoted printable.  In general any MUA should be able
to deal with either and the difference likely is no big deal.  I can
live with keeping the default at UTF8.

Stefan

[jira] [Updated] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-376:
---

Fix Version/s: (was: 1.2.12)

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-376) Race condition in AbsoluteTimeDateFormatter

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reopened LOG4NET-376:


  Assignee: (was: Dominik Psenner)

> Race condition in AbsoluteTimeDateFormatter
> ---
>
> Key: LOG4NET-376
> URL: https://issues.apache.org/jira/browse/LOG4NET-376
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.11
>Reporter: Stuart Lange
>
> AbsoluteTimeDateFormatter's caching of the "to the second" timestamp string 
> is not thread-safe.  It is possible for one thread to clear the check (that 
> this timestamp matches the currently cached "to the second" timestamp), but 
> then end up using an incorrect "to the second" timestamp string if another 
> thread has changed it in the meantime.
> In our organization, we see this bug fairly regularly because we have a mix 
> of "real time" loggers that immediately write out log lines and "batching" 
> loggers that defer logging to a background task that runs every second.  We 
> therefore regularly see log lines where the timestamp is off by a second or 
> two.
> The following unit tests demonstrates the bug:
> [TestFixture]
> [Explicit]
> public class Log4netTimestampBug
> {
> /// 
> /// This test demonstrates a bug with the log4net default time 
> formatter (Iso8601DateFormatter)
> /// where the logged timestamp can be seconds off from the actual 
> input timestamp
> /// The bug is caused to a race condition in the base class 
> AbsoluteTimeDateFormatter
> /// because this class caches the timestamp string to the second but 
> it is possible for
> /// the timestamp as written by a different thread to "sneak in" and 
> be used by another
> /// thread erroneously (the checking and usage of this string is not 
> done under a lock, only
> /// its modification) 
> /// 
> [Test]
> public void Test()
> {
> var now = DateTime.Now;
> var times = Enumerable.Range(1, 100).Select(i => 
> now.AddMilliseconds(i)).ToList();
> var sb1 = new StringBuilder();
> var sb2 = new StringBuilder();
> var task1 = Task.Run(() => WriteAllTheTimes(times, new 
> StringWriter(sb1)));
> var task2 = Task.Delay(50).ContinueWith(t => 
> WriteAllTheTimes(times, new StringWriter(sb2)));
> Task.WaitAll(task1, task2);
> var task1Strings = GetTimeStrings(sb1);
> var task2Strings = GetTimeStrings(sb2);
> var diffs = Enumerable.Range(0, times.Count).Where(i => 
> task1Strings[i] != task2Strings[i]).ToList();
> Console.WriteLine("found {0} instances where the formatted 
> timestamps are not the same", diffs.Count);
> Console.WriteLine();
> var diffToLookAt = diffs.FirstOrDefault(i => i - 10 > 0 && i + 10 
> < times.Count);
> if (diffToLookAt != 0)
> {
> Console.WriteLine("Example Diff:");
> Console.WriteLine();
> Console.WriteLine("Index Original TimestampTask 1 
> Format Task 2 Format");
> for (int i = diffToLookAt - 10; i < diffToLookAt + 10; i++)
> {
> Console.WriteLine("{0,-7}   {1}   {2}   {3}   {4}", i, 
> times[i].ToString("-MM-dd HH:mm:ss,fff"),
>   task1Strings[i], task2Strings[i], i == 
> diffToLookAt ? " DIFF HERE " : "");
> }
> }
> CollectionAssert.AreEqual(task1Strings, task2Strings);
> }
> private static List GetTimeStrings(StringBuilder sb1)
> {
> return sb1.ToString().Split(new[] {'\r', '\n'}, 
> StringSplitOptions.RemoveEmptyEntries).ToList();
> }
> private static void WriteAllTheTimes(IEnumerable times,
>  TextWriter writer)
> {
> var formatter = new Iso8601DateFormatter();
> foreach (var t in times)
> {
> formatter.FormatDate(t, writer);
> writer.WriteLine();
> }
> }
> }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

LOG4NET-405 (was Re: [VOTE] Release Log4Net 1.2.13 based on RC2)

[Stefan Bodewig]

On 2013-11-13, Dominik Psenner wrote:

> Thought of that too, but I decided to let it be in UTF8 cause its the most
> compatible format nowadays whereas ASCII is somewhat antique. What do you
> think?

IIUC ASCII would have been the implicit body encoding for log4net <
1.2.12 so when looking for a backwards compatible default this would be
the most natural choice.

I'm not sure whether setting the encoding to UTF8 triggers some sort of
different handling inside of the framweork's SMTP code even if the test
was pure ASCII.  If it doesn't, then I'm fine with UTF8.

Maybe we should send two messages with a body only containing ASCII
letters and compare the raw messages created with encoding set to ASCII
or UTF8 respectively.

Stefan

[CANCELED][VOTE] Release Log4Net 1.2.13 based on RC2

[Stefan Bodewig]

Cancelling this vote as a bug has showned up that we want to fix before
cutting another release candidate.

Stefan

Re: [VOTE] Release Log4Net 1.2.13 based on RC2

[Stefan Bodewig]

On 2013-11-13, Dominik Psenner wrote:

> To me it looks like I've broken the prior behaviour while trying to fix
> LOG4NET-354 and LOG4NET-405 remedies that. *ouch*

I see

> Quoting:
> http://msdn.microsoft.com/en-us/library/system.net.mail.mailmessage.bodyenco
> ding(v=vs.110).aspx

>> The default character set is "us-ascii".

> Here they do not mention the default encoding, but it will most likely be
> Encoding.ASCII whereas Encoding.Default will most likely yield something
> different.

Shouldn't we change body encoding's default to ASCII, then?

Stefan

Re: [VOTE] Release Log4Net 1.2.13 based on RC2

[Stefan Bodewig]

On 2013-11-13, Dominik Psenner wrote:

> 0

> LOG4NET-405 jumped in and I am about to commit a fix.

I'm not comfortable with putting that into 1.2.13.  This changes a
default value which in turn might byte people relying on the old
default.

I don't have any problem with changing the default for 1.3.

Stefan

[jira] [Commented] (LOG4NET-393) Using dynamic methods with log4net causes NullReferenceException in StackFrameItem

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-393:


The vote to release 1.2.13 is currently underway and it will likely be released 
in afew days.  When/if a Nuget package is created is outside of our control.

> Using dynamic methods with log4net causes NullReferenceException in 
> StackFrameItem
> --
>
> Key: LOG4NET-393
> URL: https://issues.apache.org/jira/browse/LOG4NET-393
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.12
> Environment: VS2012, Windows 7
>Reporter: W.R. Dittmer
>Priority: Blocker
> Fix For: 1.2.13
>
> Attachments: Log4netLambaExpressionTest.zip
>
>
> In our production code we use dynamic methods e.g. when using the factory 
> pattern. We upgraded from 1.2.10 to 1.2.12 and encountered the following 
> exception:
> log4net:ERROR An exception ocurred while retreiving stack frame information.
> System.NullReferenceException: Object reference not set to an instance of an 
> object.
>at log4net.Core.StackFrameItem..ctor(StackFrame frame) in 
> c:\Users\wilfred.dittmer\Documents\Visual Studio 
> 2012\Projects\Log4netLambaExpressionTest\log4net-1.2.12-src\log4net-1.2.12\src\Core\StackFrameItem.cs:line
>  61
> I created a test project (attached) which shows the exception occuring.
> If the method is: {System.Object 
> lambda_method(System.Runtime.CompilerServices.Closure)}
> then one cannot access the DeclaringType. The code then tries to get the 
> FullName of the null value which causes the exception.
> According to: 
> http://msdn.microsoft.com/en-us/library/system.reflection.emit.dynamicmethod.declaringtype.aspx
> "DynamicMethod.DeclaringType: Gets the type that declares the method, which 
> is always null for dynamic methods."
> So it seems best to check if DeclaringType is null and if so leave the 
> m_className set to 'NA'.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: [VOTE] Release Log4Net 1.2.13 based on RC2

[Stefan Bodewig]

On 2013-11-10,  wrote:

> Professionally I’m back to working with a .NET technology stack, so
> I’ll also try find time to contribute to .NET OSS projects again.

very much looking forward to it.

Stefan

Re: [VOTE] Release Log4Net 1.2.13 based on RC2

[Stefan Bodewig]

Great to see you here, Gert!

On 2013-11-10,  wrote:

> no build for .NET 4.5, but I assume this was already discussed before
> and is planned for a subsequent release

We introduced the 4.0 builds in 2011 mainly because of the new security
model.  Without that the 2.0 version worked just fine.  In a similiar
vain the 4.0 version is supposed to be well suited for 4.5 and we'd only
add special builds when needed.

Targeting WinRT would require quite a bit of work.

Technically, NAnt doesn't support 4.5, yet, which is a hurdle.  Also
AFAIU I wouldn't be able to target 4.0 on a machine with 4.5 installed
as it is an in-place update so building the release would require two
different Windows installations.

> do we position “net” binaries as targeting only MS .NET, or are they
> suppose to be cross-CLR / cross-platform?

The trunk of log4net (targeting log4net 1.3.x and dropping support for
.NET 1.x) uses the exact same source code to compile the net/2.0 and
mono/2.0 assemblies, there is no specific MONO define used right now.
As long as your version of Mono is recent enough (2.10 works well) the
"net" binaries should work fine.

I intend to add builds for mono-3.5 and 4.0 (based on Mono 2.10 as NAnt
has problems with Mono 3.x) to verify the newer assemblies work for them
as well.

The goal is to keep platform dependenencies to a minimum but also accept
them when needed - i.e. we wouldn't rule out supporting a certain
feature just because it wasn't supported on all platforms.

Stefan

[VOTE] Release Log4Net 1.2.13 based on RC2

[Stefan Bodewig]

Hi all,

per discussion of the last few days we intend to cut a final(?) release
from the 1.2.x branch fixing some problems with the ILog extensions and
compilation for the compact framework.

log4net 1.2.13 RC2 is available for review here:
  https://dist.apache.org/repos/dist/dev/logging/log4net
  (revision 3469)

Details of changes since 1.2.12 are in the release notes:
  http://logging.apache.org/log4net/log4net-1.2.13/release/release-notes.html

  (note, I've already committed the site ot the live system but it is
  not reachable by any links - the 1.2.12 site is the one shown by default)

I have tested this with Mono and several .NET frameworks using NAnt.

The tag is here:
  https://svn.apache.org/repos/asf/logging/log4net/tags/1.2.13RC2
  (revision 1540448)

Site:
  http://logging.apache.org/log4net/log4net-1.2.13/

RAT Report:
  http://logging.apache.org/log4net/log4net-1.2.13/rat-report.html

Votes, please.  This vote will close in 72 hours, 0900 GMT 13-Nov
2013

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!

Stefan

Re: Log4Net 1.3.0

[Stefan Bodewig]

On 2013-11-07, Stefan Bodewig wrote:

> I'll try to find some time for a short triage and come back.

Found one old bug that looked easy and relatively safe to fix, so I did
just that.  I don't intend to put more changes into the release myself.

Unless anybody else wants to do additional work, I'll cut the release
over the weekend.

Stefan

[jira] [Resolved] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-132.


Resolution: Fixed

> Environment variables are mistakenly case sensitive on windows
> --
>
> Key: LOG4NET-132
> URL: https://issues.apache.org/jira/browse/LOG4NET-132
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows, .Net 3.5
>Reporter: Matthew Gabeler-Lee
>Assignee: Stefan Bodewig
>Priority: Minor
> Fix For: 1.2.13
>
>
> On windows, environment variables are meant to be case insensitive.  Because 
> of this, in some contexts, a special IDictionary class that lowercases all 
> the keys is used to manipulate environment variables, specifically 
> ProcessStartInfo.EnvironmentVariables.
> The upshot of this, for me, is that when running under the profiler I have, 
> all the environment variables get lowercased, and my logging configuration is 
> broken, because TEMP is now temp, and log4net is treating the environment 
> variables in a case sensitive manner, from using 
> Environment.GetEnvironmentVariables(), which creates a normal case sensitive 
> Hashtable object.
> It seems that, on windows, the result of 
> Environment.GetEnvironmentVariables() should be copied into a 
> StringDictionary to get proper case insensitive behavior.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-363) System.ObjectDisposedException thrown in log4net.Layout.XmlLayoutSchemaLog4j.FormatXml ln 47

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-363.


   Resolution: Duplicate
Fix Version/s: 1.2.12

> System.ObjectDisposedException thrown in 
> log4net.Layout.XmlLayoutSchemaLog4j.FormatXml ln 47
> 
>
> Key: LOG4NET-363
> URL: https://issues.apache.org/jira/browse/LOG4NET-363
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.11
> Environment: IIS 7.0
>Reporter: David Perlman
>Priority: Minor
>  Labels: nullpointerexception
> Fix For: 1.2.12
>
>
> On line 47 in XmlLayoutSchemaLog4j there is a reference to the 
> LoggingEvent.Identity property. If this call is made after the web request is 
> finished (from a different thread) the logger throws (below the exception is 
> my sad workaround):
> log4net:ERROR [UdpAppender] ErrorCode: WriteFailure. Unable to send logging 
> event to remote host --- on port .
> System.ObjectDisposedException: Safe handle has been closed
>at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& 
> success)
>at Microsoft.Win32.Win32Native.GetTokenInformation(SafeTokenHandle 
> TokenHandle, UInt32 TokenInformationClass, SafeLocalAllocHandle 
> TokenInformation, UInt32 TokenInformationLength, UInt32& ReturnLength)
>at 
> System.Security.Principal.WindowsIdentity.GetTokenInformation(SafeTokenHandle 
> tokenHandle, TokenInformationClass tokenInformationClass)
>at System.Security.Principal.WindowsIdentity.get_User()
>at System.Security.Principal.WindowsIdentity.GetName()
>at System.Security.Principal.WindowsIdentity.get_Name()
>at log4net.Core.LoggingEvent.get_Identity()
>at log4net.Layout.XmlLayoutSchemaLog4j.FormatXml(XmlWriter writer, 
> LoggingEvent loggingEvent)
>at log4net.Layout.XmlLayoutBase.Format(TextWriter writer, LoggingEvent 
> loggingEvent)
>at log4net.Appender.AppenderSkeleton.RenderLoggingEvent(LoggingEvent 
> loggingEvent)
>at log4net.Appender.UdpAppender.Append(LoggingEvent loggingEvent)
> Workaround -
> // translate identity name
> // When logging on a thread that continues (asynchronously) after 
> the web request is finished this will throw the logging
> try
> {
> if (loggingEvent.Identity != null &&
> loggingEvent.Identity.Length > 0 &&
> 
> loggingEvent.LookupProperty(LoggingEvent.IdentityProperty) == null)
> {
> 
> loggingEvent.GetProperties()[LoggingEvent.IdentityProperty] = 
> loggingEvent.Identity ?? "identity lost";
> }
> }
> catch { }



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-383) Log4Net.Error throws VerificationException - Operation could destabilize the runtime

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-383.


   Resolution: Fixed
Fix Version/s: 1.2.12

> Log4Net.Error throws VerificationException - Operation could destabilize the 
> runtime
> 
>
> Key: LOG4NET-383
> URL: https://issues.apache.org/jira/browse/LOG4NET-383
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.10, 1.2.11
> Environment: IIS 7.5 / Win 2008 R2
> .Net 4.0
> MVC3 and WCF applications
>Reporter: Arun
> Fix For: 1.2.12
>
>
> We are running into this issue when we log errors/fatal message using 
> log4net. 
> > System.Security.VerificationException: Operation could destabilize the
> > runtime.at log4net.Core.LogImpl.Fatal(Object message, Exception
> > exception)
> Strangely this happens only when we log as Error/Fatal, Info and Debug 
> messages log perfectly fine. Because of this exception, the real exceptions 
> are getting masked and its making it very hard for us to debug in deployed 
> environments. 
> I have tried searching online but to no avail. Any help is appreciated.
> Environment details:
> IIS 7.5 / Win 2008 R2
> .Net 4.0
> MVC3 and WCF applications
> Here is the logging configuration-
>  
>
> 
>   
>  type="log4net.Config.Log4NetConfigurationSectionHandler,   log4net"/>
> 
>   
>type="log4net.Appender.RollingFileAppender">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
>   
> 
>   
>   
> 
> 
>   
> 
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-387) Mysterious characters in the log file

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-387:
---

 Priority: Critical  (was: Blocker)
Fix Version/s: (was: 1.2.10)

I'm sure this issue is important to yoi, but so far you are the only one that 
has ever reported it which makes it likely to be an environment or application 
issue - that's why I've reduced the severity.

Is there anything we can do to reproduce this?

It really looks as if something was spitting a binary into your logfile, maybe 
you are logging some user input?  Does the last log message before the trouble 
starts to happen give any hint?

> Mysterious characters in the log file
> -
>
> Key: LOG4NET-387
> URL: https://issues.apache.org/jira/browse/LOG4NET-387
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows XP, .Net 2.0 Framework, Windows Service 
> Application
>Reporter: Baha
>Priority: Critical
>  Labels: bug
>
> We have a windows service application in production. This windows service is 
> logging greatly with no issues, but sometimes it starts logging mysterious 
> characters like in this screenshot:
> https://files.secureserver.net/0sq7H3khXnoq67
> To fix this, we clean the log file, and restart the windows service again, 
> but in this way, we are loosing most of the logs (specially the 
> exception/error fired by the windows service).
> Any idea on this will be greatly appreciated.
> Baha Ashour,
> RFID Enabled Solutions
> b...@resrfid.com 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-132:
---

Fix Version/s: (was: 1.2 Maintenance Release)
   1.2.13

> Environment variables are mistakenly case sensitive on windows
> --
>
> Key: LOG4NET-132
> URL: https://issues.apache.org/jira/browse/LOG4NET-132
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows, .Net 3.5
>Reporter: Matthew Gabeler-Lee
>Priority: Minor
> Fix For: 1.2.13
>
>
> On windows, environment variables are meant to be case insensitive.  Because 
> of this, in some contexts, a special IDictionary class that lowercases all 
> the keys is used to manipulate environment variables, specifically 
> ProcessStartInfo.EnvironmentVariables.
> The upshot of this, for me, is that when running under the profiler I have, 
> all the environment variables get lowercased, and my logging configuration is 
> broken, because TEMP is now temp, and log4net is treating the environment 
> variables in a case sensitive manner, from using 
> Environment.GetEnvironmentVariables(), which creates a normal case sensitive 
> Hashtable object.
> It seems that, on windows, the result of 
> Environment.GetEnvironmentVariables() should be copied into a 
> StringDictionary to get proper case insensitive behavior.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Assigned] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reassigned LOG4NET-132:
--

Assignee: Stefan Bodewig

> Environment variables are mistakenly case sensitive on windows
> --
>
> Key: LOG4NET-132
> URL: https://issues.apache.org/jira/browse/LOG4NET-132
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows, .Net 3.5
>Reporter: Matthew Gabeler-Lee
>Assignee: Stefan Bodewig
>Priority: Minor
> Fix For: 1.2.13
>
>
> On windows, environment variables are meant to be case insensitive.  Because 
> of this, in some contexts, a special IDictionary class that lowercases all 
> the keys is used to manipulate environment variables, specifically 
> ProcessStartInfo.EnvironmentVariables.
> The upshot of this, for me, is that when running under the profiler I have, 
> all the environment variables get lowercased, and my logging configuration is 
> broken, because TEMP is now temp, and log4net is treating the environment 
> variables in a case sensitive manner, from using 
> Environment.GetEnvironmentVariables(), which creates a normal case sensitive 
> Hashtable object.
> It seems that, on windows, the result of 
> Environment.GetEnvironmentVariables() should be copied into a 
> StringDictionary to get proper case insensitive behavior.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Log4Net 1.3.0

[Stefan Bodewig]

>> If there is, I'd be happy to wait anouther week, otherwise I'd proceed
>> with the release process and rather try to get trunk back into a
>> releasable state for a quick 1.3.0 afterwards.

> Not anytime soon, sorry.

Understood.  I'll have to re-tag anyway as my fix for what became
LOG4NET-404 was incomplete (that's what you get for not even compiling
after a partial merge).

I'll try to find some time for a short triage and come back.

Stefan

[jira] [Resolved] (LOG4NET-404) assemblies for .NET 3.5 are missing ILogExtensions

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-404.


Resolution: Fixed

> assemblies for .NET 3.5 are missing ILogExtensions
> --
>
> Key: LOG4NET-404
> URL: https://issues.apache.org/jira/browse/LOG4NET-404
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.12
>    Reporter: Stefan Bodewig
> Fix For: 1.2.13
>
>




--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Created] (LOG4NET-404) assemblies for .NET 3.5 are missing ILogExtensions

[Stefan Bodewig (JIRA)]

Stefan Bodewig created LOG4NET-404:
--

 Summary: assemblies for .NET 3.5 are missing ILogExtensions
 Key: LOG4NET-404
 URL: https://issues.apache.org/jira/browse/LOG4NET-404
 Project: Log4net
  Issue Type: Bug
  Components: Core
Affects Versions: 1.2.12
Reporter: Stefan Bodewig
 Fix For: 1.2.13






--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Log4Net 1.3.0

[Stefan Bodewig]

On 2013-11-07, Dominik Psenner wrote:

>> On 2013-11-06, Dominik Psenner wrote:

>>> Maybe we can craft some other small and easy fixes that we can ship with
>>> 1.2.13.

>> Oh, even though I've already tagged the sources in svn don't let that
>> hold you back, tags are cheap.  Look through JIRA if you see anything
>> you feel fits and we'll go from there.

> I may spare some time in the weekend, thus feel free to go on.

Do you think you can have a quick look to see whether there is any
"quick fix" kind of ticket - to me nothing jumps out right now.

If there is, I'd be happy to wait anouther week, otherwise I'd proceed
with the release process and rather try to get trunk back into a
releasable state for a quick 1.3.0 afterwards.

Stefan

Re: Log4Net 1.3.0

[Stefan Bodewig]

On 2013-11-06, Dominik Psenner wrote:

> Maybe we can craft some other small and easy fixes that we can ship with
> 1.2.13.

Oh, even though I've already tagged the sources in svn don't let that
hold you back, tags are cheap.  Look through JIRA if you see anything
you feel fits and we'll go from there.

Stefan

[jira] [Resolved] (LOG4NET-393) Using dynamic methods with log4net causes NullReferenceException in StackFrameItem

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-393.


   Resolution: Fixed
Fix Version/s: (was: 1.3.0)
   1.2.13
 Assignee: (was: Stefan Bodewig)

> Using dynamic methods with log4net causes NullReferenceException in 
> StackFrameItem
> --
>
> Key: LOG4NET-393
> URL: https://issues.apache.org/jira/browse/LOG4NET-393
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.12
> Environment: VS2012, Windows 7
>Reporter: W.R. Dittmer
>Priority: Blocker
> Fix For: 1.2.13
>
> Attachments: Log4netLambaExpressionTest.zip
>
>
> In our production code we use dynamic methods e.g. when using the factory 
> pattern. We upgraded from 1.2.10 to 1.2.12 and encountered the following 
> exception:
> log4net:ERROR An exception ocurred while retreiving stack frame information.
> System.NullReferenceException: Object reference not set to an instance of an 
> object.
>at log4net.Core.StackFrameItem..ctor(StackFrame frame) in 
> c:\Users\wilfred.dittmer\Documents\Visual Studio 
> 2012\Projects\Log4netLambaExpressionTest\log4net-1.2.12-src\log4net-1.2.12\src\Core\StackFrameItem.cs:line
>  61
> I created a test project (attached) which shows the exception occuring.
> If the method is: {System.Object 
> lambda_method(System.Runtime.CompilerServices.Closure)}
> then one cannot access the DeclaringType. The code then tries to get the 
> FullName of the null value which causes the exception.
> According to: 
> http://msdn.microsoft.com/en-us/library/system.reflection.emit.dynamicmethod.declaringtype.aspx
> "DynamicMethod.DeclaringType: Gets the type that declares the method, which 
> is always null for dynamic methods."
> So it seems best to check if DeclaringType is null and if so leave the 
> m_className set to 'NA'.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-393) Using dynamic methods with log4net causes NullReferenceException in StackFrameItem

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reopened LOG4NET-393:


  Assignee: Stefan Bodewig  (was: Dominik Psenner)

> Using dynamic methods with log4net causes NullReferenceException in 
> StackFrameItem
> --
>
> Key: LOG4NET-393
> URL: https://issues.apache.org/jira/browse/LOG4NET-393
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.12
> Environment: VS2012, Windows 7
>Reporter: W.R. Dittmer
>Assignee: Stefan Bodewig
>Priority: Blocker
> Fix For: 1.3.0
>
> Attachments: Log4netLambaExpressionTest.zip
>
>
> In our production code we use dynamic methods e.g. when using the factory 
> pattern. We upgraded from 1.2.10 to 1.2.12 and encountered the following 
> exception:
> log4net:ERROR An exception ocurred while retreiving stack frame information.
> System.NullReferenceException: Object reference not set to an instance of an 
> object.
>at log4net.Core.StackFrameItem..ctor(StackFrame frame) in 
> c:\Users\wilfred.dittmer\Documents\Visual Studio 
> 2012\Projects\Log4netLambaExpressionTest\log4net-1.2.12-src\log4net-1.2.12\src\Core\StackFrameItem.cs:line
>  61
> I created a test project (attached) which shows the exception occuring.
> If the method is: {System.Object 
> lambda_method(System.Runtime.CompilerServices.Closure)}
> then one cannot access the DeclaringType. The code then tries to get the 
> FullName of the null value which causes the exception.
> According to: 
> http://msdn.microsoft.com/en-us/library/system.reflection.emit.dynamicmethod.declaringtype.aspx
> "DynamicMethod.DeclaringType: Gets the type that declares the method, which 
> is always null for dynamic methods."
> So it seems best to check if DeclaringType is null and if so leave the 
> m_className set to 'NA'.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-394) Lambda-based ILog-Extensions should catch errors

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-394:
---

Fix Version/s: (was: 1.3.0)
   1.2.13

> Lambda-based ILog-Extensions should catch errors
> 
>
> Key: LOG4NET-394
> URL: https://issues.apache.org/jira/browse/LOG4NET-394
> Project: Log4net
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.2.12
>Reporter: Gian Marco Gherardi
>Assignee: Dominik Psenner
>Priority: Minor
> Fix For: 1.2.13
>
>
> The new lambda syntax introduced with LOG4NET-290 allow wrapping log related 
> code in a lambda to be executed only if necessary. In the log4net spirit of 
> being a reliable logging system (see 
> http://logging.apache.org/log4net/release/faq.html) also the log related code 
> contained in the lambda should not block application by throwing exception 
> and so the lambda execution shluld be wrapped in a try...catch



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Log4Net 1.3.0

[Stefan Bodewig]

On 2013-11-06, Dominik Psenner wrote:

> Since LOG4NET-393 is a blocker for people who work a lot with lambda
> expressions and right now we have absolutely no idea as of when 1.3 will be
> ready we might better release 1.2.13 containing the fix for the issue.

Yeah, no problem with that, I'll try to find time to cut a new release
over the next few days.

In addition it will contain fixes for LOGNET-394 and LOG4NET-399 as this
os the state when I created the 1.2.x branch.

Stefan

[jira] [Updated] (LOG4NET-391) XmlLayoutSchemaLog4j does permit logging without properties

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-391:
---

Issue Type: Improvement  (was: Bug)

> XmlLayoutSchemaLog4j does permit logging without properties
> ---
>
> Key: LOG4NET-391
> URL: https://issues.apache.org/jira/browse/LOG4NET-391
> Project: Log4net
>  Issue Type: Improvement
>  Components: Other
>Affects Versions: 1.2.12
> Environment: Any
>Reporter: Toby
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When using the XmlLayoutSchemaLog4j layout properties are logged on a per 
> line basis.  Most of the properties are common across all lines and it is 
> inefficient to log a large amount of repetitive data.
> Log4j resolves this issue with a 'Properties' flag used to indicate whether 
> properties should be logged [1].   Log4net has no such property [2].  ...but 
> it should.
> [1] - 
> https://svn.apache.org/repos/asf/logging/log4j/tags/v1_2_17/src/main/java/org/apache/log4j/xml/XMLLayout.java
> [2] 
> http://svn.apache.org/repos/asf/logging/log4net/tags/log4net-1_2_9/src/Layout/XmlLayoutSchemaLog4j.cs



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Log4Net 1.3.0

[Stefan Bodewig]

On 2013-11-06, Nick Williams wrote:

> LOG4NET-393 is causing us some problems at $work. It's fixed as of
> 1.3.0, which doesn't appear to be released yet. Is there an expected
> date for it to be released, and if not what can I do to help make this
> happen?

If you need anything fast, then it is probably easier to cut 1.2.13 from
the 1.x branch - 1.3.x is still undergoing quite a bit of non-productive
reshuffling.

> And while I have your attention, I noticed that we released the
> log4net NuGet package for 1.2.10 as "1.2.10", but 1.2.11 and 1.2.12
> were "2.0.0" and "2.0.1," respectively. 1.2.12 was then re-released as
> "2.0.2." Since I've only been with Apache Logging since the spring and
> I'm completely new to log4net, can someone shed some light on all of
> this for me? It doesn't make a whole lot of sense. Thanks.

The NuGet package is not provided by us, we don't have any influence on
or insight into it.



Stefan

Re: Build failed in Jenkins: log4net-trunk-tests #2

[Stefan Bodewig]

On 2013-11-05, Dominik Psenner wrote:

> Glad you've been able to reproduce it, but I can't recall that I had a
> firewall at all that could block me. But who knows - sometimes firewalls
> behave more like invisiwalls. :-)

This is Jenkins, our CI now runs the tests (on .NET 4.0 for now).

Strange thing is the next build passed and the changes I've made are
completely unrelated.  Could it be a load issue?  Jenkins felt sluggish
a few hours ago but seems better now.

Stefan

Re: Build failed in Jenkins: log4net-trunk-tests #2

[Stefan Bodewig]

woohoo!

On 2013-11-05, Apache Jenkins Server wrote:

>[nunit2] Test Case Failures:
>[nunit2] 1) log4net.Tests.Appender.RemotingAppenderTest.TestFullFix :   
> Expect to receive 1 remoted event
>[nunit2]   Expected: 1
>[nunit2]   But was:  0
>[nunit2]
>[nunit2] at log4net.Tests.Appender.RemotingAppenderTest.TestFullFix() in 
> :line
>  127

I guess this is the test failure Dominik has seen as well.

This time I vaguely recall "clicking away" a firewall warning when I ran
the tests for the first time - so the test probably fails because the
firewall doesn't allow the connection to be made.

Stefan

Re: Changed some defines

[Stefan Bodewig]

On 2013-11-05, Dominik Psenner wrote:

>>> Having a general FRAMEWORK_X_Y define wouldn't be bad. But maybe
>> every
>>> FRAMEWORK_X_Y should read as "FRAMEWORK_X_Y_OR_ABOVE" since
>> every framework
>>> is compatible to its ancestors.

>> fine with me, I'll make the adjustments.

> Awesome.

not yet done, but will do :-)

>>> Still I would keep these defines:

>>> * MONO := set when build for Mono
>>> * MONO_X_Y := set when built for Mono
>>> * DOTNET := set when built for the .NET framework

>> What you call DOTNET currently is NET, but that will be easy to change.
>> In addition we still have NETCF for Compact Framework.

>> My hope is we don't need MONO_X_Y but only MONO and the matching
>> FRAMEWORK_X_Y_OR_ABOVE.  We'll see once we try to target Mono 3.5 and
>> 4.0 as well but I'd rather reduce the repetition all our different build
>> targets cause in the build files, first.

> So we assume an implicit DOTNET as long as there is no MONO, right?

or NETCF, yes.  We still define NET (or DOTNET soonish) but I don't
think it is actually used in the sources.

Stefan

Re: Changed some defines

[Stefan Bodewig]

On 2013-11-04, Dominik Psenner wrote:

> Having a general FRAMEWORK_X_Y define wouldn't be bad. But maybe every
> FRAMEWORK_X_Y should read as "FRAMEWORK_X_Y_OR_ABOVE" since every framework
> is compatible to its ancestors.

fine with me, I'll make the adjustments.

> Still I would keep these defines:

> * MONO := set when build for Mono
> * MONO_X_Y := set when built for Mono
> * DOTNET := set when built for the .NET framework

What you call DOTNET currently is NET, but that will be easy to change.
In addition we still have NETCF for Compact Framework.

My hope is we don't need MONO_X_Y but only MONO and the matching
FRAMEWORK_X_Y_OR_ABOVE.  We'll see once we try to target Mono 3.5 and
4.0 as well but I'd rather reduce the repetition all our different build
targets cause in the build files, first.

> building for a newer .NET framework should define all other frameworks
> since every future framework will be compatible to all ancestors. For
> example while building for .NET 4.0 the following defines should be
> set:

> {FRAMEWORK_2_0_OR_ABOVE, FRAMEWORK_3_0_OR_ABOVE, FRAMEWORK_3_5_OR_ABOVE,
> FRAMEWORK_4_0_OR_ABOVE, DOTNET}

Agreed in general, but given FRAMEWORK_2_0_OR_ABOVE is our baseline I'd
assume it implicitly for all builds (that are not NETCF).  Also
FRAMEWORK_3_0_OR_ABOVE wouldn't be used for anything and I don't expect
us to use it.  Let's introduce it once we need it.

> Despite all this, I'm not sure if we need something like
> FRAMEWORK_X_Y_ONLY.  This would need further evaluation based on the
> current codebase.

There is no such case right now.  We really only have a single place
where 3.5 is checked and it is enabled for 4.0 as well.

If we ever need it, we can simulate it with something like

#if FRAMEWORK_3_5_OR_ABOVE && !FRAMEWORK_4_0_OR_ABOVE 

Stefan

[jira] [Assigned] (LOG4NET-71) Reorganise source repository to support multiple src projects

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reassigned LOG4NET-71:
-

Assignee: Stefan Bodewig

> Reorganise source repository to support multiple src projects
> -
>
> Key: LOG4NET-71
> URL: https://issues.apache.org/jira/browse/LOG4NET-71
> Project: Log4net
>  Issue Type: Task
>Reporter: Nicko Cadell
>        Assignee: Stefan Bodewig
> Fix For: 1.3.0
>
>
> The log4net source code repository needs to be updated to allow multiple 
> projects under the src folder. Currently the source for the log4net assembly 
> is directly in the src folder.
> A better structure would be:
> src/
> log4net/
> log4net.Tests/
> log4net.Experimental/
> xdocs/
> We may want to move the examples in to the src folder, or we may want to 
> leave then outside.
> The major impact of this change is to the NAnt build scripts that we use to 
> build the log4net assembly, the examples and the tests.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Changed some defines

[Stefan Bodewig]

Hi all,

I have removed all defines that correspond to frameworks trunk no longer
builds and also dropped the *_2_0 symbols as they are the default now -
on that way I've removed a few chunks of 1.x specific code.

For the Compact Framework 2.0 build I'll ask Dustin Jones, the reporter
of LOG4NET-399 to verify I haven't broken things.

Also I changed NET_3_5 and NET_4_0 to FRAMEWORK_3_5 and FRAMEWORK_4_0,
the idea is that we reuse those symbols for Mono as well and make it
switch on API versions rather than implementations.  Does that make
sense?

Unfortunately I somehow missed the introduction of NET_3_5 which was not
part of the build setup.  This means the 3.5 builds of 1.2.12 do no
contain the ILog extension methods.  In new trunk builds they now do,
which also means the 3.5 version is now really different from the 2.0
one.

Finally I'm thinking about defining FRAMEWORK_3_5 for the net-4.0 build
as well so 

#if FRAMEWORK_3_5 || FRAMEWORK_4_0

could be collapsed to 

#if FRAMEWORK_3_5

and each conditional could just use the one version the required feature
has first been added in.

Stefan

[FWD] Re: svn commit: r1538346 - in /logging/log4net/trunk: LICENSE NOTICE tests/lib/nunit.framework.dll tests/lib/prerequisites.txt tests/nant.build

[Stefan Bodewig]

[BTW, I've re-enabled running the tests in Jenkins, not sure whether it
is going to work - the Windows slave is currently offline :-(]

On 2013-11-03,  wrote:

> Log:
> NUnit's license should be compatible, so stop copying around stuff and
> just check it in

Just for the record: in fact NUnit's license[1] is the zlib license[2]
which is listed under Category A [3].

Stefan

[1] http://nunit.org/index.php?p=license&r=2.6.3
[2] http://opensource.org/licenses/zlib-license.php
[3] http://www.apache.org/legal/resolved.html#category-a

Site generation

[Stefan Bodewig]

On 2013-11-03, Dominik Psenner wrote:

> On 11/02/2013 10:41 AM, Stefan Bodewig wrote:
>> On 2013-11-01, Dominik Psenner wrote:

>>> 2013/11/1 Stefan Bodewig 
>>>> I'd like restructure our codebase a little as it feels a bit scattered
>>>> to me, in particular I'd like to move
>>>> src/* => src/main/* (except for site)
>>>> tests => src/tests
>>>> examples => src/examples
>>>> extensions => src/extensions
>>> And maybe src/site to some other place like doc/website and split the
>>> build process so that site and src are no longer tightly bound to each
>>> other?
>> OK, this will take some POM massage - or moving away from maven for the
>> website build, which I wouldn't mind at all.
> The smaller the required tool set, the better it would be. I'm sure
> you know which way's the best.

Not really.

I think the docs used to be static HTML files and were switched to Maven
in order to make it easier to share the L&F with the rest of Logging.
But in fact, much of logging (main site, log4j and log4php) is using a
different skin by now.

The other benefit was removing the boilerplate HTML required for each
and every page.

I'm not sure which tool would be easier for us, not sure whether there'd
be some markdown => html solution that could be run from within NAnt or
what else NAnt could offer in that space.  XSLT would certainly work but
not really simplifies anything.

Another option might be to use the Apache CMS for our static
documentation and only add the API docs from our build - that would
imply we'd no longer ship the documentation pages with the log4net
distribution.

Stefan

Re: Moving files around in trunk

[Stefan Bodewig]

On 2013-11-01, Dominik Psenner wrote:

> 2013/11/1 Stefan Bodewig 

>> I'd like restructure our codebase a little as it feels a bit scattered
>> to me, in particular I'd like to move

>> src/* => src/main/* (except for site)
>> tests => src/tests
>> examples => src/examples
>> extensions => src/extensions

> And maybe src/site to some other place like doc/website and split the
> build process so that site and src are no longer tightly bound to each
> other?

OK, this will take some POM massage - or moving away from maven for the
website build, which I wouldn't mind at all.

>> BTW, I've just finished setting up a new VM for log4net development.
>> Now that I can drop 1.x I went for Win7, installed SDKs for .NET 2.0,
>> 3.5 and 4.0 as well as Mono 2.10 and now have a single environment that
>> builds all target frameworks expeceted for 1.3 - and could also target
>> mono-3.5 and mono-4.0.  This should be possible to re-create on any Win7
>> box without requiring stuff you'd need an MSDN subscription for.

> Would you like to share the VM (if possible with respect to licensing
> etc)?

Licensing is a problem as it has to run a version of Windows 7
(professional in my case).  Sharing the installer packages for the rest
is easy but it will still take a few hours of work to re-build the VM
with repeatedly installing updates and all that.

Stefan

Re: examples and extensions

[Stefan Bodewig]

On 2013-11-01, Dominik Psenner wrote:

> TBH, neither have I. The examples should probably be integrated better into
> the website by "tutorializing" them and include in those tutorials a link
> to the source of a single example.

Sounds good, just needs to be done :-)

Stefan

examples and extensions

[Stefan Bodewig]

Hi,

I don't think I've ever built the extension, in fact I wouldn't even
know what they contain without looking it up.  The situation is similar
for the examples.

We'd need to modernize them in some way and maybe add new examples like
for the new extensions methods API.

This could be a nice "simple task" for people who want to start
contributing to log4net.

Stefan

Moving files around in trunk

[Stefan Bodewig]

Hi,

I'd like restructure our codebase a little as it feels a bit scattered
to me, in particular I'd like to move

src/* => src/main/* (except for site)
tests => src/tests
examples => src/examples
extensions => src/extensions

and I'd like to modify the build files so that assemblies and all
documentation is created in a common directory - rooted under build or
target, you name it:

bin => $TARGET/assembly
doc/sdk => $TARGET/site/current/sdk

does that make sense?

Stefan

BTW, I've just finished setting up a new VM for log4net development.
Now that I can drop 1.x I went for Win7, installed SDKs for .NET 2.0,
3.5 and 4.0 as well as Mono 2.10 and now have a single environment that
builds all target frameworks expeceted for 1.3 - and could also target
mono-3.5 and mono-4.0.  This should be possible to re-create on any Win7
box without requiring stuff you'd need an MSDN subscription for.

Re: Thoughts on 1.3

[Stefan Bodewig]

On 2013-10-25, Dominik Psenner wrote:

>> * the next release will be 1.3.0 and require .NET 2.0 or better

>>  I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0,
>>  Mono < 2.0, SSCLI and CLI 1.0 frameworks

> That's even worth a +2! ;-)

>> * the main assembly will get a new name like log4net-13.dll, only be
>>  signed by the new key

>> * we provide two assemblies named log4net.dll signed with the old and
>>  new key respecitvely that contain type forwards to the new assembly
>>  only

> I'm afraid that I can't quite grasp all the stuff we could break. We should
> definitely work out every possible usecase we may break. We have messed
> enough and should try to not raise the tempers even more.

Understood, I'll take that to the user list for a bigger audience -
maybe people will see problems that we are overlooking.

>> stuff we haven't talked about, yet:

>> * I'd like to split log4net-13.dll so that the main assembly can be used
>>  for the client profile and a separate assembly contains the stuff that
>>  requires System.Web - this way we no longer need the -cp builds.

> The client profile was dropped with .NET 4.5 and previous versions are
> automatically upgraded to include the missing DLLs once somebody runs an
> update. Thus I'm not sure if we should really split the library and double
> the required efforts.

I see.  I wasn't aware the client profile was dropped again - spending
most if not all of my working hours in Java land has made me lose track,
or so it seems.  In that case splitting the assembly doesn't make to
much sense.

And the client profile builds can be removed when log4net drops support
for .NET 4.0 ten years from now ;-)

Thanks

Stefan

Thoughts on 1.3

[Stefan Bodewig]

Hi all,

this is just a random list, I'd like to make sure whether we are on the
same page before making changes or just give the user list a heads up.

My understanding of the discussion which basically happened in JIRA so
far:

* the next release will be 1.3.0 and require .NET 2.0 or better

  I.e. we remove support for .NET 1.0 and 1.1, Compact Framework 1.0,
  Mono < 2.0, SSCLI and CLI 1.0 frameworks

* the main assembly will get a new name like log4net-13.dll, only be
  signed by the new key

* we provide two assemblies named log4net.dll signed with the old and
  new key respecitvely that contain type forwards to the new assembly
  only

stuff we haven't talked about, yet:

* I'd like to split log4net-13.dll so that the main assembly can be used
  for the client profile and a separate assembly contains the stuff that
  requires System.Web - this way we no longer need the -cp builds.

* add support for Mono 4.0

  Actually I currently can only build Mono 2.0 and 4.0 and 2.0 will be
  gone once I replace my really old home machine.  I guess I need to
  investigate running separate Mono installations in parallel.

* .NET 4.5?  Is there anything special about 4.5 or does the 4.0 version
  just work?

* give the user list a heads up so they know about our plans and can
  tell us to stop if necessary.

Stefan

Re: svn commit: r1531076 - in /logging/log4net/trunk/src: Core/StackFrameItem.cs Util/ThreadContextProperties.cs

[Stefan Bodewig]

On 2013-10-10,  wrote:

> Modified: logging/log4net/trunk/src/Util/ThreadContextProperties.cs
> URL: 
> http://svn.apache.org/viewvc/logging/log4net/trunk/src/Util/ThreadContextProperties.cs?rev=1531076&r1=1531075&r2=1531076&view=diff
> ==
> --- logging/log4net/trunk/src/Util/ThreadContextProperties.cs (original)
 logging/log4net/trunk/src/Util/ThreadContextProperties.cs Thu Oct 10 
 18:55:19 2013
>   internal PropertiesDictionary GetProperties(bool create)
>   {
> - if (_dictionary != null && create)
> - {
> - return new PropertiesDictionary(_dictionary);
> + #if NETCF
> + PropertiesDictionary _dictionary = 
> (PropertiesDictionary)System.Threading.Thread.GetData(s_threadLocalSlot);
> + #endif
> + if (_dictionary == null && create)
> + {

Note I've modified the meaning of GetProperties(true) here and brought
it back in line with what the documentation says (and back to what
1.2.11 did).

When _dictionary was null, the method used to create a new dictionary
but in 1.2.12 returns null - I think this is a bug.  OTOH if it was not
null then 1.2.12 returned a new dictionary instance in the create ==
true case - now it will always return the existing one.

This doesn't really matter, though, as the method is internal and no
code ever invoked GetProperties(true) in 1.2.12 - at least that's what
grep says.

Stefa

[jira] [Commented] (LOG4NET-398) SerializationException after setting a LogicalThreadContext property

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-398:


http://www.logue.com.ar/blog/2007/12/cassini-serializationexception-type-is-not-resolved-for-member/
 hints at a problem with the embedded WebHost of VS and classes that use 
CallContext.SetData - even if the article is old, so is the Bug raised against 
VS linked from it and it still unresolved.  Comments in the report indicate the 
problem exists in VS2010 as well.

Dominik, are you using VS2010 and the embedded host or are you using something 
newer than that?

Sounds like the webhost was creating multiple appdomains and log4net wasn't 
available in all of them.



> SerializationException after setting a LogicalThreadContext property
> 
>
> Key: LOG4NET-398
> URL: https://issues.apache.org/jira/browse/LOG4NET-398
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.12
> Environment: Visual Studio 2010
>Reporter: Thomas Meum
>
> I have found that accessing Page.Request.Url after setting a 
> LogicalThreadContext property causes a SerializationException with the 
> following message: Type is not resolved for member 
> 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.12.0, 
> Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'.
> I have been able to reproduce the problem on two different machines with the 
> following steps:
> 1. Create a new ASP.NET Empty Web Application
> 2. Add a reference to log4net.dll
> 3. Add a new Web Form
> 4. Add the following code to Page_Load:
> log4net.LogicalThreadContext.Properties["Test"] = 1;
> Uri url = Request.Url;
> 5. Hit F5



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-383) Log4Net.Error throws VerificationException - Operation could destabilize the runtime

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-383:


LOG4NET-318 maybe?

> Log4Net.Error throws VerificationException - Operation could destabilize the 
> runtime
> 
>
> Key: LOG4NET-383
> URL: https://issues.apache.org/jira/browse/LOG4NET-383
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.10, 1.2.11
> Environment: IIS 7.5 / Win 2008 R2
> .Net 4.0
> MVC3 and WCF applications
>Reporter: Arun
>
> We are running into this issue when we log errors/fatal message using 
> log4net. 
> > System.Security.VerificationException: Operation could destabilize the
> > runtime.at log4net.Core.LogImpl.Fatal(Object message, Exception
> > exception)
> Strangely this happens only when we log as Error/Fatal, Info and Debug 
> messages log perfectly fine. Because of this exception, the real exceptions 
> are getting masked and its making it very hard for us to debug in deployed 
> environments. 
> I have tried searching online but to no avail. Any help is appreciated.
> Environment details:
> IIS 7.5 / Win 2008 R2
> .Net 4.0
> MVC3 and WCF applications
> Here is the logging configuration-
>  
>
> 
>   
>  type="log4net.Config.Log4NetConfigurationSectionHandler,   log4net"/>
> 
>   
>type="log4net.Appender.RollingFileAppender">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
>   
> 
>   
>   
> 
> 
>   
> 
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-397:


http://svn.apache.org/viewvc/logging/log4net/trunk/src/site/xdoc/release/faq.xml?r1=1530611&r2=1530610&pathrev=1530611
 - will be published soon.

> Conflicts due to new strong name key
> 
>
> Key: LOG4NET-397
> URL: https://issues.apache.org/jira/browse/LOG4NET-397
> Project: Log4net
>  Issue Type: Bug
>Reporter: Joe
>
> Consider an application that uses two third-party assemblies:
> - AssemblyA from Supplier A, compiled with log4net 1.2.10 (old strong-name 
> key)
> - AssemblyB from Supplier B, compiled with log4net 1.2.11 (new strong-name 
> key)
> How can I make these two assemblies co-exist and use the same version of 
> log4net?
> Maybe I'm missing something obvious, but I can't see any way to do this: for 
> example I obviously can't have both log4net assemblies in the same bin 
> folder, as they have the same name.
> I'm obviously not the only one who thinks there's a problem, e.g. issue 
> LOG4NET-324 refers to "... the strong name horror too".  The comment on this 
> issue:
> "... But if you need the old "strong name", you can simply use the "oldkey" 
> binaries. I can't see how this is a horror, but of course I'm biased."
> doesn't seem to address the problem of conflicts.
> Also there are no guidelines for component suppliers as to which version to 
> use, which increases the risk of conflicts.  In the absence of explicit 
> guidelines, I guess legacy components will have the old key, whereas new ones 
> will tend to use the new key, since that is the only version available via 
> NuGet.
> The only solution I can see is the following:
> - The "new key" assembly needs to have a different name from the "old key" 
> assembly (e.g. log4net-2.dll).
> - Use Type forwarding to enable both versions to co-exist.  E.g. you could 
> supply a special log4net.dll signed with the old key that uses type 
> forwarding to forward to log4net-2.dll signed with the new key.  Or 
> vice-versa.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reopened LOG4NET-395:



> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-358) Visual Studio snippet within the deployment with NuGet

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-358.


Resolution: Won't Fix

"invalid" is not a proper resolution for an existing bug we just can't fix.

> Visual Studio snippet within the deployment with NuGet
> --
>
> Key: LOG4NET-358
> URL: https://issues.apache.org/jira/browse/LOG4NET-358
> Project: Log4net
>  Issue Type: Wish
>  Components: Builds
> Environment: Visual Studio deployment with NuGet
>Reporter: Luciano
>Priority: Minor
>  Labels: deployment, log4net, nuget
>
> The deployment with NuGet for Visual Studio could installs also a snippet 
> which could be used to declare a private static reference to logger 
> "log4net.ILog". So, after installed the log4net via NuGet, we could just go 
> to any class and type log and a full and auto declaration appears 
> referencing the enclosure type.
> Following is a snippet I use today with C#, but needs to be installed apart 
> on each Visual Studio installation. The main piece of the snippet is the 
> declaration: private static readonly log4net.ILog log = 
> log4net.LogManager.GetLogger(typeof($classname$));
> SNIPPET DECLARATION:
> 
>  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet";>
>   
> 
>   
> Expansion
>   
>   log4net - Declaration
>   Luciano
>   
>   
>   
>   
>   log
>   
> 
> 
>   
>   
> log4net.dll
>   
>   
>   
> 
>   classname
>   
>   
>   
>   ClassName()
>   
> 
>   
>   
>   
>   
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-358) Visual Studio snippet within the deployment with NuGet

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reopened LOG4NET-358:



> Visual Studio snippet within the deployment with NuGet
> --
>
> Key: LOG4NET-358
> URL: https://issues.apache.org/jira/browse/LOG4NET-358
> Project: Log4net
>  Issue Type: Wish
>  Components: Builds
> Environment: Visual Studio deployment with NuGet
>Reporter: Luciano
>Priority: Minor
>  Labels: deployment, log4net, nuget
>
> The deployment with NuGet for Visual Studio could installs also a snippet 
> which could be used to declare a private static reference to logger 
> "log4net.ILog". So, after installed the log4net via NuGet, we could just go 
> to any class and type log and a full and auto declaration appears 
> referencing the enclosure type.
> Following is a snippet I use today with C#, but needs to be installed apart 
> on each Visual Studio installation. The main piece of the snippet is the 
> declaration: private static readonly log4net.ILog log = 
> log4net.LogManager.GetLogger(typeof($classname$));
> SNIPPET DECLARATION:
> 
>  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet";>
>   
> 
>   
> Expansion
>   
>   log4net - Declaration
>   Luciano
>   
>   
>   
>   
>   log
>   
> 
> 
>   
>   
> log4net.dll
>   
>   
>   
> 
>   classname
>   
>   
>   
>   ClassName()
>   
> 
>   
>   
>   
>   
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-395) Nuget packaging problem - Creates app.config file in ALL projects when applying package.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-395.


Resolution: Won't Fix

"invalid" is not a proper resolution for an existing bug we just can't fix.

> Nuget packaging problem - Creates app.config file in ALL projects when 
> applying package.
> 
>
> Key: LOG4NET-395
> URL: https://issues.apache.org/jira/browse/LOG4NET-395
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.9, 1.2.10, 1.2.12
>Reporter: Adam Lith
>
> When installing (or updating!) the log4net nuget package it either:
> * Adds an app.config file if none exists
> * Transforms the app.config file if one exists.
> And it does this to all the projects that you apply the package to (as always 
> with nuget).
> This is incredibly annoying because then I have to manually delete the config 
> files or revert the transformations.
> The common practice for nuget-packaging is to not perform zero transforms or 
> content-type additions and instead supply a link in the description of the 
> package to a tutorial for those that don's know how to get started.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-392.


Resolution: Won't Fix

we'd like to see this fixed but can't fix it as the Nuget package is controlled 
by somebody else.

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Reopened] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig reopened LOG4NET-392:



sorry, I can't seem to change the resolution without re-opening the issue.

Mark, you are right, invalid doesn't fit as good as I thought it would.

Nobody is trying to hide anything, we are just admitting that we cannot do 
anything at all.

I've personally contacted the folks who provide the Nuget package, we are 
trying hard to cooperate.

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-392:
---

Component/s: (was: Builds)

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Updated] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig updated LOG4NET-392:
---

Labels: nuget patch  (was: patch)

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Resolved] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig resolved LOG4NET-392.


Resolution: Invalid

This is "invalid" as we don't control the nuget package.

See also 
http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/
 and https://github.com/cincuranet/log4net-nuget

If the issue persists, I'd encourage you to open an issue at github

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: nuget, patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-358) Visual Studio snippet within the deployment with NuGet

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-358:


see also 
http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/
 and https://github.com/cincuranet/log4net-nuget

If the issue persists, I'd encourage you to open an issue at github

> Visual Studio snippet within the deployment with NuGet
> --
>
> Key: LOG4NET-358
> URL: https://issues.apache.org/jira/browse/LOG4NET-358
> Project: Log4net
>  Issue Type: Wish
>  Components: Builds
> Environment: Visual Studio deployment with NuGet
>Reporter: Luciano
>Priority: Minor
>  Labels: deployment, log4net, nuget
>
> The deployment with NuGet for Visual Studio could installs also a snippet 
> which could be used to declare a private static reference to logger 
> "log4net.ILog". So, after installed the log4net via NuGet, we could just go 
> to any class and type log and a full and auto declaration appears 
> referencing the enclosure type.
> Following is a snippet I use today with C#, but needs to be installed apart 
> on each Visual Studio installation. The main piece of the snippet is the 
> declaration: private static readonly log4net.ILog log = 
> log4net.LogManager.GetLogger(typeof($classname$));
> SNIPPET DECLARATION:
> 
>  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet";>
>   
> 
>   
> Expansion
>   
>   log4net - Declaration
>   Luciano
>   
>   
>   
>   
>   log
>   
> 
> 
>   
>   
> log4net.dll
>   
>   
>   
> 
>   classname
>   
>   
>   
>   ClassName()
>   
> 
>   
>   
>   
>   
> 
>   
> 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: NuGet package distribution

[Stefan Bodewig]

On 2013-10-08, Dominik Psenner wrote:

>> Never heard back, but with
>> > some-goodies/>
>> and  we could simply point
>> people to github and close all Nuget related issues immediately.

> +1

> Given the noise, an entry in the FAQ could be wise.

Probably - and maybe a pointer from the download page.

I'll take care of it tomorrow unless you beat me to it.

Stefan

Re: NuGet package distribution

[Stefan Bodewig]

On 2013-10-04, Stefan Bodewig wrote:

> I've contacted "cincura.net" via the NuGet website and hope to hear
> back.  It would be great to have her/him on board addressing the
> packaging related issues and maybe help streamline the process of
> publishing future packages.

Never heard back, but with
<http://blog.cincura.net/233419-log4net-nuget-package-updated-without-some-goodies/>
and <https://github.com/cincuranet/log4net-nuget> we could simply point
people to github and close all Nuget related issues immediately.

Stefan

Re: Is it time to move to 2.0?

[Stefan Bodewig]

On 2013-10-08, Dominik Psenner wrote:

> 1.2.11 already contained breaking changes and so did 1.2.12. Thus I would
> not mind breaking backwards compatibility within 1.X even further. The next
> good milestone could be 1.3 RC1 since we won't be compatible with log4j2 and
> we should go to 2.X only if we port log4j2 features into log4net.

At least in JIRA I've set the expectation 2.x would be the version that
drops .NET 1.x support.  But that can be rectified easily.

Would you also drop .NET 1.x support in 1.3.x then?

Stefan

Is it time to move to 2.0?

[Stefan Bodewig]

Hi all,

not sure whether I find an audience big enough or whether we need to
expand this to the user list.

One option to get out of the oldkey/newkey problems mentioned in
https://issues.apache.org/jira/browse/LOG4NET-397 would be to make the
move to a log4net2 assembly.

The short term plan would be:

* branch off a 1.x branch from trunk in case we want to do a 1.2.13
  release one day

* remove the 1.x, Mono 1.x and compact framework builds

* start ripping out the .NET 1.x compatibility code as well as all
  NET_20 conditionals

* rename assembly to log4net2 - only sign it with the "new key"

* create log4net assemblies holding type forwarders to log4net2 -
  provide two versions with either key

* release soon

Pros:

* allows us to build all of log4net on Windows7 - right now I must keep
  an XP VM around and we all know XP will see an end of live soon.

* fixes the binding problems

Cons:

* lognet4 2.x would look like log4j 1.x not 2.x - this might confuse
  people.  Then again I don't envision us to port log4j2 any time soon
  because of our sheer lack of manpower.

* we'd lose an opportunity to remove more stuff we'd like to break
  backwards compatibility on - at least if "release soon" was taken
  seriously

WDYT?

Stefan

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-397:


So far I had assumed you had no influence on the suppliers :-)

When we swiitched to the new key two years ago, there was strong demand for 
supporting 1.x - believe it or not.

While the current setup may be inconvenient or in your case more than just 
that, breaking existing setups that use the new-key log4net assembly by 
renaming it again wouldn't be a change people would welcome either.

There is a hypotetcical log4net 2.x which was allowed to break backwards 
compatibility and so on.  This one should have a different file name as well - 
maybe it is time to cut a 2.x release with oldkey and newkey log4net assemblies 
that both contain type forwarders to a newkey log4net2 assembly only.  I'll 
open a discussion for this on the dev and maybe even the user list and we'll 
see where it goes.  You'd be more than welcome to voice your opinion there.  
JIRA tickets aren't really a good place for discussion, much less decision 
making.

> Conflicts due to new strong name key
> 
>
> Key: LOG4NET-397
> URL: https://issues.apache.org/jira/browse/LOG4NET-397
> Project: Log4net
>  Issue Type: Bug
>Reporter: Joe
>
> Consider an application that uses two third-party assemblies:
> - AssemblyA from Supplier A, compiled with log4net 1.2.10 (old strong-name 
> key)
> - AssemblyB from Supplier B, compiled with log4net 1.2.11 (new strong-name 
> key)
> How can I make these two assemblies co-exist and use the same version of 
> log4net?
> Maybe I'm missing something obvious, but I can't see any way to do this: for 
> example I obviously can't have both log4net assemblies in the same bin 
> folder, as they have the same name.
> I'm obviously not the only one who thinks there's a problem, e.g. issue 
> LOG4NET-324 refers to "... the strong name horror too".  The comment on this 
> issue:
> "... But if you need the old "strong name", you can simply use the "oldkey" 
> binaries. I can't see how this is a horror, but of course I'm biased."
> doesn't seem to address the problem of conflicts.
> Also there are no guidelines for component suppliers as to which version to 
> use, which increases the risk of conflicts.  In the absence of explicit 
> guidelines, I guess legacy components will have the old key, whereas new ones 
> will tend to use the new key, since that is the only version available via 
> NuGet.
> The only solution I can see is the following:
> - The "new key" assembly needs to have a different name from the "old key" 
> assembly (e.g. log4net-2.dll).
> - Use Type forwarding to enable both versions to co-exist.  E.g. you could 
> supply a special log4net.dll signed with the old key that uses type 
> forwarding to forward to log4net-2.dll signed with the new key.  Or 
> vice-versa.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-397:


type forwarding wouldn't work for 1.x - I could claim this is the reason we 
didn't use them even if this isn't true.  But in fact if we had thought of type 
forwards this would have ruled out the solution.

> Conflicts due to new strong name key
> 
>
> Key: LOG4NET-397
> URL: https://issues.apache.org/jira/browse/LOG4NET-397
> Project: Log4net
>  Issue Type: Bug
>Reporter: Joe
>
> Consider an application that uses two third-party assemblies:
> - AssemblyA from Supplier A, compiled with log4net 1.2.10 (old strong-name 
> key)
> - AssemblyB from Supplier B, compiled with log4net 1.2.11 (new strong-name 
> key)
> How can I make these two assemblies co-exist and use the same version of 
> log4net?
> Maybe I'm missing something obvious, but I can't see any way to do this: for 
> example I obviously can't have both log4net assemblies in the same bin 
> folder, as they have the same name.
> I'm obviously not the only one who thinks there's a problem, e.g. issue 
> LOG4NET-324 refers to "... the strong name horror too".  The comment on this 
> issue:
> "... But if you need the old "strong name", you can simply use the "oldkey" 
> binaries. I can't see how this is a horror, but of course I'm biased."
> doesn't seem to address the problem of conflicts.
> Also there are no guidelines for component suppliers as to which version to 
> use, which increases the risk of conflicts.  In the absence of explicit 
> guidelines, I guess legacy components will have the old key, whereas new ones 
> will tend to use the new key, since that is the only version available via 
> NuGet.
> The only solution I can see is the following:
> - The "new key" assembly needs to have a different name from the "old key" 
> assembly (e.g. log4net-2.dll).
> - Use Type forwarding to enable both versions to co-exist.  E.g. you could 
> supply a special log4net.dll signed with the old key that uses type 
> forwarding to forward to log4net-2.dll signed with the new key.  Or 
> vice-versa.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-397) Conflicts due to new strong name key

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-397:


Joe, you are right.  When we considered switching to a new strong name key, the 
scenario of two different dependencies requiring two different strong names 
never came up.  Back then type forwarding might have been the better option, 
but unfortunately nobobdy thought of it.

Right now renaming won't help in your case, would it?  AssemblyB would still be 
bound to the name log4net.

>From the top of my head and without having a .NET installation at hand to try 
>my theory: you could create subdirectories inside your application directory 
>and place the two log4net assemblies in separate subdirs. Using a privatePath 
>attribute on a probing element in your application's config you should be able 
>to load both versions.

> Conflicts due to new strong name key
> 
>
> Key: LOG4NET-397
> URL: https://issues.apache.org/jira/browse/LOG4NET-397
> Project: Log4net
>  Issue Type: Bug
>Reporter: Joe
>
> Consider an application that uses two third-party assemblies:
> - AssemblyA from Supplier A, compiled with log4net 1.2.10 (old strong-name 
> key)
> - AssemblyB from Supplier B, compiled with log4net 1.2.11 (new strong-name 
> key)
> How can I make these two assemblies co-exist and use the same version of 
> log4net?
> Maybe I'm missing something obvious, but I can't see any way to do this: for 
> example I obviously can't have both log4net assemblies in the same bin 
> folder, as they have the same name.
> I'm obviously not the only one who thinks there's a problem, e.g. issue 
> LOG4NET-324 refers to "... the strong name horror too".  The comment on this 
> issue:
> "... But if you need the old "strong name", you can simply use the "oldkey" 
> binaries. I can't see how this is a horror, but of course I'm biased."
> doesn't seem to address the problem of conflicts.
> Also there are no guidelines for component suppliers as to which version to 
> use, which increases the risk of conflicts.  In the absence of explicit 
> guidelines, I guess legacy components will have the old key, whereas new ones 
> will tend to use the new key, since that is the only version available via 
> NuGet.
> The only solution I can see is the following:
> - The "new key" assembly needs to have a different name from the "old key" 
> assembly (e.g. log4net-2.dll).
> - Use Type forwarding to enable both versions to co-exist.  E.g. you could 
> supply a special log4net.dll signed with the old key that uses type 
> forwarding to forward to log4net-2.dll signed with the new key.  Or 
> vice-versa.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: NuGet package distribution

[Stefan Bodewig]

On 2013-10-04, Dominik Psenner wrote:

> Recently the noise about NuGet packages became louder and the time has come
> talk about this. We know of two open issues that have to be addressed by the
> owner of the NuGet package distribution:

> https://issues.apache.org/jira/browse/LOG4NET-395
> https://issues.apache.org/jira/browse/LOG4NET-392


> Since it is not obvious that we, the ASF Apache Logging Services, do
> not maintain those we should try to get "cincura.net" on board or do
> something else that does not discriminate whoever uses NuGet to get
> log4net.

Fully agreed.  I've contacted "cincura.net" via the NuGet website and
hope to hear back.  It would be great to have her/him on board
addressing the packaging related issues and maybe help streamline the
process of publishing future packages.

Stefan

[jira] [Commented] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-392:


I've contacted the NuGet package's owner via the NuGet website, we'll see.


> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-392) Updating causing Config issue

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-392:


we don't build/provide NuGet packages and TBH I don't have any idea who has 
created the existing ones.

> Updating causing Config issue
> -
>
> Key: LOG4NET-392
> URL: https://issues.apache.org/jira/browse/LOG4NET-392
> Project: Log4net
>  Issue Type: Bug
>  Components: Builds
>Affects Versions: 1.2.12
> Environment: Windows 7 (64 bit) using Visual Studio 2012, NHibernate, 
> and Postgres
>Reporter: Mark Strandness
>  Labels: patch
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I did an update yesterday from the VS 2012 NuGet Manager and afterwards, keep 
> getting a Configuration.Cfg error on my NHibernate. Found where you have 
> changed the log4net config and it added a second config for the log4net 
> package. 
> 
>   
>  \/ type="log4net.Config.Log4NetConfigurationSectionHandler,Log4net" />
>type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
>  
>   /\
> I commented out the bottom line and I now have an operational system again. 
> Small error but for the size of this system, very time consumming. Almost 
> ripped out all the log4net system to go elsewhere, but I saved it..
> Make your update soon before many other people have this same issue.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-232:


no need to be sorry.  And thank you for checking!

> Use ReaderWriterLockSlim instead of ReaderWriterLock.
> -
>
> Key: LOG4NET-232
> URL: https://issues.apache.org/jira/browse/LOG4NET-232
> Project: Log4net
>  Issue Type: Improvement
>Affects Versions: 1.2.10
> Environment: Any
>Reporter: Aron Weiler
>Assignee: Dominik Psenner
>Priority: Minor
> Fix For: 1.2.12
>
>
> ReaderWriterLock should be replaced with ReaderWriterLockSlim according to 
> Microsoft for performance and simplification reasons.
> MSDN: 
> http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx
> The .NET Framework has two reader-writer locks, ReaderWriterLockSlim and 
> ReaderWriterLock. ReaderWriterLockSlim is recommended for all new 
> development. ReaderWriterLockSlim is similar to ReaderWriterLock, but it has 
> simplified rules for recursion and for upgrading and downgrading lock state. 
> ReaderWriterLockSlim avoids many cases of potential deadlock. In addition, 
> the performance of ReaderWriterLockSlim is significantly better than 
> ReaderWriterLock. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-232:


In that case my VM won't help as it runs XP SP3.

Do you know what kind of exception is raised on older systems?

> Use ReaderWriterLockSlim instead of ReaderWriterLock.
> -
>
> Key: LOG4NET-232
> URL: https://issues.apache.org/jira/browse/LOG4NET-232
> Project: Log4net
>  Issue Type: Improvement
>Affects Versions: 1.2.10
> Environment: Any
>Reporter: Aron Weiler
>Assignee: Dominik Psenner
>Priority: Minor
> Fix For: 1.2.12
>
>
> ReaderWriterLock should be replaced with ReaderWriterLockSlim according to 
> Microsoft for performance and simplification reasons.
> MSDN: 
> http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx
> The .NET Framework has two reader-writer locks, ReaderWriterLockSlim and 
> ReaderWriterLock. ReaderWriterLockSlim is recommended for all new 
> development. ReaderWriterLockSlim is similar to ReaderWriterLock, but it has 
> simplified rules for recursion and for upgrading and downgrading lock state. 
> ReaderWriterLockSlim avoids many cases of potential deadlock. In addition, 
> the performance of ReaderWriterLockSlim is significantly better than 
> ReaderWriterLock. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

[Stefan Bodewig (JIRA)]

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

Stefan Bodewig commented on LOG4NET-232:


.NET 4.0 is available for XP, so this doesn't help.  Mike is probably right and 
the change has broken support for people using the .NET 4.0 assembly on XP.

I'll try to write a testcase for this on my XP VM and find a workaround.

> Use ReaderWriterLockSlim instead of ReaderWriterLock.
> -
>
> Key: LOG4NET-232
> URL: https://issues.apache.org/jira/browse/LOG4NET-232
> Project: Log4net
>  Issue Type: Improvement
>Affects Versions: 1.2.10
> Environment: Any
>Reporter: Aron Weiler
>Assignee: Dominik Psenner
>Priority: Minor
> Fix For: 1.2.12
>
>
> ReaderWriterLock should be replaced with ReaderWriterLockSlim according to 
> Microsoft for performance and simplification reasons.
> MSDN: 
> http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx
> The .NET Framework has two reader-writer locks, ReaderWriterLockSlim and 
> ReaderWriterLock. ReaderWriterLockSlim is recommended for all new 
> development. ReaderWriterLockSlim is similar to ReaderWriterLock, but it has 
> simplified rules for recursion and for upgrading and downgrading lock state. 
> ReaderWriterLockSlim avoids many cases of potential deadlock. In addition, 
> the performance of ReaderWriterLockSlim is significantly better than 
> ReaderWriterLock. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ANN] Apache log4net 1.2.12 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache log4net team is pleased to announce the release of Apache
log4net 1.2.12.  The release is available for download at

http://logging.apache.org/log4net/download_log4net.cgi

The Apache log4net library is a tool to help the programmer output log
statements to a variety of output targets.  log4net is a port of the
excellent Apache log4j framework to the Microsoft(R) .NET runtime.

log4net 1.2.12 is mostly a bugfix release in which more than thirty JIRA
issues have been resolved.  See

http://logging.apache.org/log4net/release/release-notes.html

for a full list of changes.

The binary distributions no longer contain assemblies built for the
Compact Framework 2.0 - you can build those yourself using the source
distribution.

Please verify signatures using the KEYS file available at the above
location when downloading the release.

For complete information on log4net, including instructions on how to
submit bug reports, patches, or suggestions for improvement, see the
Apache log4net website:

http://logging.apache.org/log4net/

Stefan Bodewig on behalf of the log4net community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlIxzRUACgkQohFa4V9ri3IeWwCfQjoUIoVZGRTNsIJlZVVa+skG
tssAn1yV9K7RzKtoNJomOETAexuhvSC7
=L7zJ
-END PGP SIGNATURE-