headers
Dan Händevik (JIRA | 19 May 2013 20:13
Picon
Favicon

[jira] [Commented] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10


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

Dan Händevik commented on LOG4NET-377:
--------------------------------------

So from what I can understand, there is no official version of log4net that is lower than 1.2.11? Both 1.2.9
and 1.2.10 are marked as incubator versions and code compiled against those versions are not compatible
with 1.2.11?

> XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
> -----------------------------------------------------------------------
>
>                 Key: LOG4NET-377
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-377
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.11
>         Environment: .net 2 (and probably other versions as well
>            Reporter: Dan Händevik
>            Assignee: Dominik Psenner
>            Priority: Blocker
>
> The log4net.Config.XmlConfiguration method ConfigureAndWatch(FileInfo) differs from version
1.2.10 and 1.2.11.
> In 10 it has void as return value and in 1.2.11 it returns an ICollection.
> If I compile against 1.2.10 and then replaces the dll  with 1.2.11 and uses an assembly redirect to use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominik Psenner (JIRA | 18 May 2013 11:25
Picon
Favicon

[jira] [Commented] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10


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

Dominik Psenner commented on LOG4NET-377:
-----------------------------------------

The official build is available only on apache.org

> XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
> -----------------------------------------------------------------------
>
>                 Key: LOG4NET-377
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-377
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.11
>         Environment: .net 2 (and probably other versions as well
>            Reporter: Dan Händevik
>            Assignee: Dominik Psenner
>            Priority: Blocker
>
> The log4net.Config.XmlConfiguration method ConfigureAndWatch(FileInfo) differs from version
1.2.10 and 1.2.11.
> In 10 it has void as return value and in 1.2.11 it returns an ICollection.
> If I compile against 1.2.10 and then replaces the dll  with 1.2.11 and uses an assembly redirect to use the
newer version I'll get a runtime error stating
> Method not found: 'Void log4net.Config.XmlConfigurator.ConfigureAndWatch(System.IO.FileInfo)'.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Händevik (JIRA | 18 May 2013 10:51
Picon
Favicon

[jira] [Commented] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10


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

Dan Händevik commented on LOG4NET-377:
--------------------------------------

Correct me if I'm wrong, but the method that returns void is present in the 1.2.10 that i added from the nuget
feed (http://nuget.org/packages/log4net/1.2.10). Is this not your official version of 1.2.10? is
this a BETA version that has been put up on nuget?

> XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
> -----------------------------------------------------------------------
>
>                 Key: LOG4NET-377
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-377
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.11
>         Environment: .net 2 (and probably other versions as well
>            Reporter: Dan Händevik
>            Assignee: Dominik Psenner
>            Priority: Blocker
>
> The log4net.Config.XmlConfiguration method ConfigureAndWatch(FileInfo) differs from version
1.2.10 and 1.2.11.
> In 10 it has void as return value and in 1.2.11 it returns an ICollection.
> If I compile against 1.2.10 and then replaces the dll  with 1.2.11 and uses an assembly redirect to use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominik Psenner (JIRA | 18 May 2013 08:57
Picon
Favicon

[jira] [Commented] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10


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

Dominik Psenner commented on LOG4NET-377:
-----------------------------------------

https://issues.apache.org/jira/browse/LOG4NET-2 states that this breaking change was done with
revision 607475 and thus was released along with 1.2.10. Therefore you have been using log4net
1.2.9-BETA and, by being a beta, was subject to API breaking changes.

> XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
> -----------------------------------------------------------------------
>
>                 Key: LOG4NET-377
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-377
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.11
>         Environment: .net 2 (and probably other versions as well
>            Reporter: Dan Händevik
>            Assignee: Dominik Psenner
>            Priority: Blocker
>
> The log4net.Config.XmlConfiguration method ConfigureAndWatch(FileInfo) differs from version
1.2.10 and 1.2.11.
> In 10 it has void as return value and in 1.2.11 it returns an ICollection.
> If I compile against 1.2.10 and then replaces the dll  with 1.2.11 and uses an assembly redirect to use the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Händevik (JIRA | 18 May 2013 08:15
Picon
Favicon

[jira] [Commented] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10


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

Dan Händevik commented on LOG4NET-377:
--------------------------------------

I cannot agree with your conclusion that this is expected behavior.
First of all, the version number does not indicate that the release contains any breaking changes. I guess
that you don't conform to semantic versioning (http://semver.org/) but many .net libraries does and
this is almost a standard now adays so I strongly suggest that you should look into that.
Secondly on your release notes page
 http://logging.apache.org/log4net/release/release-notes.html
you state that this is a buggix release. A bugfix release does not (in my opinion) introduces any breaking changes.
Third, on the same page you include a list of breaking changes but this list only contains one post and it is
not this issue.

I cannot say that any of the above indicates to me that this is expected behavior.
Frankly, I doubted myself at first. I must have seen wrong.

It's not much work to keep a library backwards compatible.
Do not change any public signatures. If you invent a new signature (like adding a return value), give it a new
name and make the old one obsolete instead.
This will keep backwards compability but issue a compiler warning that indicates the intended change for
the user.
Removing obsolete code should only be done on a major release (when changing the major version number)

Log4net is a great .net library but if I cannot trust the stability of the releases then I cannot continue
using the library in my own projects. My users can update their log4net nuget packages and that will break
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominik Psenner (JIRA | 18 May 2013 07:21
Picon
Favicon

[jira] [Closed] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10


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

Dominik Psenner closed LOG4NET-377.
-----------------------------------

    Resolution: Won't Fix
      Assignee: Dominik Psenner

This is expected behaviour and won't be fixed. If you want to move on you'll have to recompile your assembly
that depends on log4net.

> XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
> -----------------------------------------------------------------------
>
>                 Key: LOG4NET-377
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-377
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.11
>         Environment: .net 2 (and probably other versions as well
>            Reporter: Dan Händevik
>            Assignee: Dominik Psenner
>            Priority: Blocker
>
> The log4net.Config.XmlConfiguration method ConfigureAndWatch(FileInfo) differs from version
1.2.10 and 1.2.11.
> In 10 it has void as return value and in 1.2.11 it returns an ICollection.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Händevik (JIRA | 17 May 2013 23:13
Picon
Favicon

[jira] [Created] (LOG4NET-377) XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10

Dan Händevik created LOG4NET-377:
------------------------------------

             Summary: XmlConfigurator.ConfigureAndWatch is not backwards compatible to 1.2.10
                 Key: LOG4NET-377
                 URL: https://issues.apache.org/jira/browse/LOG4NET-377
             Project: Log4net
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.2.11
         Environment: .net 2 (and probably other versions as well
            Reporter: Dan Händevik
            Priority: Blocker

The log4net.Config.XmlConfiguration method ConfigureAndWatch(FileInfo) differs from version
1.2.10 and 1.2.11.
In 10 it has void as return value and in 1.2.11 it returns an ICollection.

If I compile against 1.2.10 and then replaces the dll  with 1.2.11 and uses an assembly redirect to use the
newer version I'll get a runtime error stating
Method not found: 'Void log4net.Config.XmlConfigurator.ConfigureAndWatch(System.IO.FileInfo)'.

--
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
Permalink | Reply | 0 comments |
headers
Dominik Psenner (JIRA | 17 May 2013 08:41
Picon
Favicon

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


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

Dominik Psenner commented on LOG4NET-376:
-----------------------------------------

Regarding ThreadStatic: I did not do performance timings, thus I do not know if it would perform better. My
believe is that this attribute could tear down performance in heavily cross-threaded environments by
practically disabling the cache. Generally I do not think it is wise to have code behaving one way in multi
threading and another way in single threading. It makes the code terribly hard to maintain and therefore I
would not want to take a foot on that road unless there are good arguments to do so.

Regarding the drop of static: changing the cache to be instance specific would practically make it
ineffective since it would happen in every formatter instance whereas it needs to be done only once every
second. So that would have a performance impact too which probably is bigger than a pure lock. The way
Stefan fixed LOG4NET-323 seems to be perfectly fine to me.

It is widely known that thread safety does not come for free. If you believe that the performance impact is
not neglectable I would like to encourage you to do some performance timings for these scenarios:

* "Rev 1483378" in Single Thread
* "Rev 1380139 + ThreadStatic" in Single Thread
* "Rev 1483378" in Multi Thread
* "Rev 1380139 + ThreadStatic" in Multi Thread

> Race condition in AbsoluteTimeDateFormatter
> -------------------------------------------
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart Lange (JIRA | 16 May 2013 23:43
Picon
Favicon

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


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

Stuart Lange commented on LOG4NET-376:
--------------------------------------

I could also be convinced that locking the whole method is okay if all the static state were changed to
instance state -- that would also have fixed LOG4NET-323, without requiring the dictionary of strings.

> 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
>            Assignee: Dominik Psenner
>             Fix For: 1.2.12
>
>
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart Lange (JIRA | 16 May 2013 23:41
Picon
Favicon

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


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

Stuart Lange commented on LOG4NET-376:
--------------------------------------

Thanks for having a look.  I have a feeling that people will get concerned about the performance
implications of locking the entire method.  I share that concern a bit, as this is a static lock object, so
you are effectively synchronizing all calls to this method across the entire application.  Have you
considered removing the locking and instead marking all the mutable static fields ThreadStatic? http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx

> 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
>            Assignee: Dominik Psenner
>             Fix For: 1.2.12
>
>
> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominik Psenner (JIRA | 16 May 2013 16:09
Picon
Favicon

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


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

Dominik Psenner commented on LOG4NET-376:
-----------------------------------------

I've commited a second fix as 1483378. Please look at both revisions as being a single patch. Sorry for the noise.

> 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
>            Assignee: Dominik Psenner
>             Fix For: 1.2.12
>
>
> 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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane