Maxim Cherednik (JIRA | 30 Jul 11:02 2015
Picon

[jira] [Updated] (LOG4NET-469) Fixes for the LogicalThreadContext - NDC stack is wrong


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

Maxim Cherednik updated LOG4NET-469:
------------------------------------
    Fix Version/s: 1.3.0

> Fixes for the LogicalThreadContext - NDC stack is wrong
> -------------------------------------------------------
>
>                 Key: LOG4NET-469
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-469
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.3.0
>            Reporter: Maxim Cherednik
>             Fix For: 1.3.0
>
>
> This is related to issue number 455. (Link to github: https://github.com/apache/log4net/pull/12)
> I was playing around with this fix recently and came across some strange behavior.
> Imagine main method:
> {code:title=main.cs|borderStyle=solid}
> using (LogicalThreadContext.Stacks["NDC"].Push("Start"))
> {
>     // init all the stuff here
>     _timer.TimerElapsed += TimerOnTimerElapsed;
> }
(Continue reading)

Maxim Cherednik (JIRA | 30 Jul 10:58 2015
Picon

[jira] [Updated] (LOG4NET-469) Fixes for the LogicalThreadContext - NDC stack is wrong


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

Maxim Cherednik updated LOG4NET-469:
------------------------------------
    Summary: Fixes for the LogicalThreadContext - NDC stack is wrong  (was: Fixes for the LogicalThreadContext)

> Fixes for the LogicalThreadContext - NDC stack is wrong
> -------------------------------------------------------
>
>                 Key: LOG4NET-469
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-469
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.3.0
>            Reporter: Maxim Cherednik
>
> This is related to issue number 455. (Link to github: https://github.com/apache/log4net/pull/12)
> I was playing around with this fix recently and came across some strange behavior.
> Imagine main method:
> {code:title=main.cs|borderStyle=solid}
> using (LogicalThreadContext.Stacks["NDC"].Push("Start"))
> {
>     // init all the stuff here
>     _timer.TimerElapsed += TimerOnTimerElapsed;
> }
> {code}
> An that would be it.
(Continue reading)

Maxim Cherednik (JIRA | 30 Jul 10:56 2015
Picon

[jira] [Created] (LOG4NET-469) Fixes for the LogicalThreadContext

Maxim Cherednik created LOG4NET-469:
---------------------------------------

             Summary: Fixes for the LogicalThreadContext
                 Key: LOG4NET-469
                 URL: https://issues.apache.org/jira/browse/LOG4NET-469
             Project: Log4net
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.3.0
            Reporter: Maxim Cherednik

This is related to issue number 455. (Link to github: https://github.com/apache/log4net/pull/12)

I was playing around with this fix recently and came across some strange behavior.
Imagine main method:
{code:title=main.cs|borderStyle=solid}
using (LogicalThreadContext.Stacks["NDC"].Push("Start"))
{
    // init all the stuff here
    _timer.TimerElapsed += TimerOnTimerElapsed;
}
{code}
An that would be it.

When I am on the timer tick event I have another context:

{code:title=timer.cs|borderStyle=solid}
using (LogicalThreadContext.Stacks["NDC"].Push("timer"))
{
(Continue reading)

Michel Emond (JIRA | 28 Jul 21:37 2015
Picon

[jira] [Commented] (LOG4NET-465) Rolling log files get overwritten when IIS is restarted


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

Michel Emond commented on LOG4NET-465:
--------------------------------------

Hello, any news about this one? Thanks!

> Rolling log files get overwritten when IIS is restarted
> -------------------------------------------------------
>
>                 Key: LOG4NET-465
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-465
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 1.2.13
>         Environment: asp.net 4.0
>            Reporter: Michel Emond
>         Attachments: RollingFileAppender.diff, config.xml
>
>
> This is the issue described in LOG4NET-378
> h2. Reproduction steps
> # Setup a web application using the settings from the attached config.xml file
> # Notice the rolling style set to Composite
> # Start and use the application
> # The log files pile up in the folder
(Continue reading)

Edwin Rios (JIRA | 15 Jul 02:11 2015
Picon

[jira] [Commented] (LOG4NET-468) Problem when use "PreserveLogFileNameExtension=true" and "CountDirection=0"


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

Edwin Rios commented on LOG4NET-468:
------------------------------------

Hello,

Thanks for answer.

What I can see is when "CountDirection" property is "0", and "PreserveLogFileNameExtension" is "false",
the file name continue incrementing normally, like versions 1.2.10 and like the documentation says.

But when "CountDirection" property is "0", and "PreserveLogFileNameExtension" is "true", it fails.

https://logging.apache.org/log4net/release/sdk/index.html

log4net.Appender.RollingFileAppender.CountDirection

Remarks
CountDirection >= 0 does the opposite i.e. log.1 is the first backup made, log.5 is the 5th backup made, etc.
For infinite backups use CountDirection >= 0 to reduce rollover costs.

Thanks

> Problem when use "PreserveLogFileNameExtension=true" and "CountDirection=0"
> ---------------------------------------------------------------------------
>
(Continue reading)

Dominik Psenner (JIRA | 15 Jul 00:08 2015
Picon

[jira] [Commented] (LOG4NET-468) Problem when use "PreserveLogFileNameExtension=true" and "CountDirection=0"


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

Dominik Psenner commented on LOG4NET-468:
-----------------------------------------

At first sight, a CountDirection of 0 does not make much sense. How would you expect log4net to handle that case?

> Problem when use "PreserveLogFileNameExtension=true" and "CountDirection=0"
> ---------------------------------------------------------------------------
>
>                 Key: LOG4NET-468
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-468
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.13
>         Environment: Windows Server 2003
>            Reporter: Edwin Rios
>            Priority: Minor
>
> I was using the Log4Net 1.2.10 (Framework 2.0) and I needed to use "CountDirection" property but also I
needed to have the same file extension, but in this version the backup file name is like "xxxx.log.1". So, I
searched and found that the version 1.2.13 have the "PreserveLogFileNameExtension" property, so I
decided to test it.
> But I found that when I use the "PreserveLogFileNameExtension = true" and  the "CountDirection = 0", the
"CountDirection" does not increment  the name of the backup file, only until ONE.
> The xml in web.config looks like this:
(Continue reading)

Edwin Rios (JIRA | 14 Jul 21:21 2015
Picon

[jira] [Created] (LOG4NET-468) Problem when use "PreserveLogFileNameExtension=true" and "CountDirection=0"

Edwin Rios created LOG4NET-468:
----------------------------------

             Summary: Problem when use "PreserveLogFileNameExtension=true" and "CountDirection=0"
                 Key: LOG4NET-468
                 URL: https://issues.apache.org/jira/browse/LOG4NET-468
             Project: Log4net
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.2.13
         Environment: Windows Server 2003
            Reporter: Edwin Rios
            Priority: Minor

I was using the Log4Net 1.2.10 (Framework 2.0) and I needed to use "CountDirection" property but also I
needed to have the same file extension, but in this version the backup file name is like "xxxx.log.1". So, I
searched and found that the version 1.2.13 have the "PreserveLogFileNameExtension" property, so I
decided to test it.

But I found that when I use the "PreserveLogFileNameExtension = true" and  the "CountDirection = 0", the
"CountDirection" does not increment  the name of the backup file, only until ONE.

The xml in web.config looks like this:
  <log4net>
      <!--Log AplicaciĆ³n-->
      <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender,log4net">
        <param name="File" value="./logs/777_Trace" />
        <param name="AppendToFile" value="true" />
        <param name="RollingStyle" value="Composite" />
        <param name="DatePattern" value="_yyyy-MM-dd'.log'" />
(Continue reading)

Dominik Psenner (JIRA | 12 Jul 22:26 2015
Picon

[jira] [Commented] (LOG4NET-467) Is .NET Core, will be supported in the near future, or not


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

Dominik Psenner commented on LOG4NET-467:
-----------------------------------------

It is probably too early to comment or even decide what work will have to be done on log4net when dotnet core
gets released. It might be possible that log4net is already compatible because, in a nutshell, dotnet
core packs everything platform specific into separate libraries that are referened, fetched and
included locally on demand. All the rest mostly stays the same. But that might be just me oversimplifying things.

Nevertheless: If you require log4net to work together with dotnet core, you should start to work on it for
yourselve and share the results! It would be impudent to let others do your work. As you know most of us do
this in our sparetime and everyone has its own priority queue. On mine there is no dotnet core, yet. :-)

As for the other question, Log4net does its job and when it doesnt it gets its attention. Major releases are
neither planned, nor required at the moment. It has its position in the apache logging family and there is
no reason why this should change in the near future.

Hth, d.

> Is .NET Core, will be supported in the near future, or not
> ----------------------------------------------------------
>
>                 Key: LOG4NET-467
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-467
>             Project: Log4net
>          Issue Type: New Feature
(Continue reading)

san kan (JIRA | 10 Jul 03:59 2015
Picon

[jira] [Created] (LOG4NET-467) Is .NET Core, will be supported in the near future, or not

san kan created LOG4NET-467:
-------------------------------

             Summary: Is .NET Core, will be supported in the near future, or not
                 Key: LOG4NET-467
                 URL: https://issues.apache.org/jira/browse/LOG4NET-467
             Project: Log4net
          Issue Type: New Feature
          Components: Core
    Affects Versions: 1.2.13
            Reporter: san kan

As you know, ms is moving heavily toward .Net core:
https://github.com/dotnet/core

so, is there a road map for making a version that supports it?

and i noticed that log4net, has not been updated for 2 years.

so is it maintained, or being forgotten?

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Dominik Psenner (JIRA | 29 Jun 08:53 2015
Picon

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


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

Dominik Psenner commented on LOG4NET-398:
-----------------------------------------

Apologies, [~Nellemandela]. I'm rather busy with debugging a baby. :-) It would be nice if someone else
could look into this as I won't get a chance to do it anytime soon.

> SerializationException after setting a LogicalThreadContext property
> --------------------------------------------------------------------
>
>                 Key: LOG4NET-398
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-398
>             Project: Log4net
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 1.2.12
>         Environment: Visual Studio 2010
>            Reporter: Thomas Meum
>            Priority: Minor
>              Labels: triaged
>         Attachments: log4net.zip
>
>
> 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'.
(Continue reading)

Picon

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


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

Lars Nellemann Nielsen commented on LOG4NET-398:
------------------------------------------------

[~nachbarslumpi] Have you had a chance to test the attached solution ?

> SerializationException after setting a LogicalThreadContext property
> --------------------------------------------------------------------
>
>                 Key: LOG4NET-398
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-398
>             Project: Log4net
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 1.2.12
>         Environment: Visual Studio 2010
>            Reporter: Thomas Meum
>            Priority: Minor
>              Labels: triaged
>         Attachments: log4net.zip
>
>
> 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:
(Continue reading)


Gmane