.NET 4.0 support

[Dominik Psenner]

Greetings,

first of all I would like to present myself as a new member of the
log4net-devel mailing list. :-) And right away I start with my question.

I issued the problem that log4net is not compatible with .NET 4.0 and as
such I ask if this is going to change?

So basically this mail should lead to a small discussion if it would meet
the project roadmap and if it should be targeted in a future release.

Greetings,
D.

AW: [jira] Updated: (LOG4NET-245) Need information on Exception Handling mechanism used in Log4Net project

[Dominik Psenner]

Good morning.

What are you about to accomplish with that exception filter?

I'm quite sure log4net internally has no exception filter installed as it
would make no sense (at least it stands to reason for me). But I may also be
on the wrong boat.

And externally (i.e. by something like Logger.InstallExceptionFilter() in
your Main()) makes no sense either, as it is your responsibility to capture
and handle exceptions and not of the logging system that should only provide
the features to log a exception that occurred for diagnostic purposes.

Greetings from Italy,
D.

-Ursprüngliche Nachricht-
Von: Rajat Raina (JIRA) [mailto:j...@apache.org] 
Gesendet: Mittwoch, 10. Februar 2010 08:16
An: log4net-dev@logging.apache.org
Betreff: [jira] Updated: (LOG4NET-245) Need information on Exception
Handling mechanism used in Log4Net project


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

Rajat Raina updated LOG4NET-245:


Priority: Blocker  (was: Major)

> Need information on Exception  Handling mechanism used in Log4Net project
> -
>
> Key: LOG4NET-245
> URL: https://issues.apache.org/jira/browse/LOG4NET-245
> Project: Log4net
>  Issue Type: Task
>Affects Versions: 1.2.10
> Environment: XP
>Reporter: Rajat Raina
>Priority: Blocker
>
> I need some information as we are working on a common Exception handling
framework for all our code.
> Can you please let me know if Log4Net dll defines any Exception filters
through the usage of Microsoft's SetUnhandledExceptionFilter?
> I need this information for my common exception handling framework
designing.
> Please let me know!
> Thanks!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

AW: [jira] Created: (LOG4NET-251) RollingFileAppender with rollingStyle="Date" and maximumFileSize both are not working Simultaneously.

[Dominik Psenner]

Does this also happen if you limit the filesize to something bigger like
500k or more?

-Ursprüngliche Nachricht-
Von: rakesh (JIRA) [mailto:j...@apache.org] 
Gesendet: Montag, 15. März 2010 07:41
An: log4net-dev@logging.apache.org
Betreff: [jira] Created: (LOG4NET-251) RollingFileAppender with
rollingStyle="Date" and maximumFileSize both are not working Simultaneously.

RollingFileAppender with rollingStyle="Date"  and maximumFileSize both are
not working Simultaneously. 

---

 Key: LOG4NET-251
 URL: https://issues.apache.org/jira/browse/LOG4NET-251
 Project: Log4net
  Issue Type: Bug
  Components: Appenders
 Environment: windows-7 OS
Reporter: rakesh


I have one problem with RollingFileAppender Type.
when i am create a configuration with rollingstyle=Date and with
maximumFileSize=1 KB. then also appender is write a more then 1 kb. of file
size.
now we remove a  rollingstyle=Date then it works fine with maximumFileSize.
is there are any problem with maximumFileSize and rollingstyle=Date ?



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

AW: [jira] Updated: (LOG4NET-256) log4net With MDC is not exactly threadsafe?

[Dominik Psenner]

Good morning.

As I understood your problem and the way log4net (and other log4*) works, a
logger is identified by its name, which is passed into the
LogManager.GetLogger(type) constructor delegator. Log4net then instantiates
exactly this one logger and gives you back the instance in future calls. If
you use it multiple times across different classes, you have of course the
same instance of the logger across these different classes.

So, to fix this problem, I would recommend using log4net as it was designed
and try one of these two things:

* do a LogManager.GetLogger(type) across the classes, hold there a instance
for this class in a static variable and pass it to the log helper. This
actually renders the log helper pretty useless, but it works.

* Implement the log helper as a wrapper and provide a constructor method
just like the LogManager.GetLogger(type) does. You may even provide a
interface that your helper implements. That way you would be able to switch
helper and implementation transparently and change logging facility in the
future.

* You can of course implement the second attempt so that it automatically
detects which class called the method and therefore looking up your class
for itself. Refer to c# reflections and examine the callstack in .NET. Note
that these operations cost a lot of performance.

Greetings,
D.

-Ursprüngliche Nachricht-
Von: MK Pandey (JIRA) [mailto:j...@apache.org] 
Gesendet: Montag, 26. April 2010 06:56
An: log4net-dev@logging.apache.org
Betreff: [jira] Updated: (LOG4NET-256) log4net With MDC is not exactly
threadsafe?


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

MK Pandey updated LOG4NET-256:
--

Attachment: bug detals mail.jpg

> log4net With MDC is not exactly threadsafe?
> ---
>
> Key: LOG4NET-256
> URL: https://issues.apache.org/jira/browse/LOG4NET-256
> Project: Log4net
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.2.10
> Environment: Windows Server 2003, Windows XP
>Reporter: MK Pandey
> Attachments: bug detals mail.jpg
>
>
> Hi All, 
> Our situation is that we are using MDC values (ex, transID) to set
additional values which is used across multiple classes to identify the
transaction. 
> We have one LogHelper class which creates private static instance of the
as below: 
> log4net.ILog fileLogger = LogManager.GetLogger(GetType()); 
> When second thread starts and modifies the values, the subsequent logs
from other threads start using the same values. 
> Any suggestions? 
> When using web.config file for appender defintion, is this not thread
safe? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

AW: [jira] Created: (LOG4NET-257) Visual Studio 2010 .NET 4.0 Application does not copy log4net lib to bin directory

[Dominik Psenner]

There are more compatibility problems with log4net and .NET 4.0 and actually
nobody knows what will be.

AW: abandoned?

[Dominik Psenner]

Good news that maybe something is moving on. My last note regarding .net 4.0
support was never answered and just resides somewhere in the history of
February (see:
http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201002.mbox/%3C
bc2abb510f3f405f9be041b89be06...@alpin.local%3e ).

I agree with a minor release (1.3 or so) that marks the currently stable
codebase.

But as long there are no breaking API changes needed to get log4net running
with .net4.0 I would not target it as a major release, but more or less a
1.4.x.

Greetings,
d.

-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:bode...@apache.org] 
Gesendet: Montag, 3. Mai 2010 06:08
An: log4net-dev@logging.apache.org
Betreff: Re: abandoned?

On 2010-05-03, Ron Grabowski  wrote:

> I agree with getting out a small point release before a large refactor.

+1

You may even consider to change the major version with the refactoring,
i.e. release a 1.1 compatible log4net 1.2.x soon and call the .NET 2.0+
version log4net 2.x

Stefan

RE: abandoned?

[Dominik Psenner]

You're right. But for now I would leave out the generics. It is likely more
urgent that log4net works with .NET 4.0 right now because a lot of people
(like us) plan a UI rewrite with XAML in the next few months. I sense this
as the main stream of .NET in the near future.

> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org]
> Sent: Monday, May 03, 2010 10:16 AM
> To: log4net-dev@logging.apache.org
> Subject: Re: abandoned?
> 
> On 2010-05-03, Dominik Psenner  wrote:
> 
> > But as long there are no breaking API changes needed to get log4net
> running
> > with .net4.0 I would not target it as a major release, but more or less
> a
> > 1.4.x.
> 
> Ron talked about taking advantage of generics in the API which would be
> a breaking change.  Otherwise I agree with you that changing the major
> version shouldn't be required.
> 
> Stefan

RE: My custome appender does not work

[Dominik Psenner]

Hi.

May you wanna try to instantiate the appender by code to see if the
configuration is not used / wrong? I suspect that it can't find and
instantiate your class by
type="Alfaplan.Carola.Prototype.Logging.CustomeAppender".

Greetings,
d.

> -Original Message-
> From: Nadesh [mailto:nadeshik...@hotmail.com]
> Sent: Friday, May 14, 2010 11:49 AM
> To: log4net-dev@logging.apache.org
> Subject: My custome appender does not work
> 
> 
> Hello everyone!
> 
> I have created a new custome appender which shows a box message:
> 
> namespace Alfaplan.Carola.Prototype.Logging
> {
> class CustomeAppender : log4net.Appender.AppenderSkeleton
> {
> 
> protected override void Append(log4net.Core.LoggingEvent
> loggingEvent)
> {
> MessageBox.Show("Message Sent: " +
> loggingEvent.RenderedMessage);
> }
> }
> }
> 
> And an xml file which is used to launch the appender:
> 
> 
>   
>  type="Alfaplan.Carola.Prototype.Logging.CustomeAppender">
>   
>   
> 
> 
> 
>   
> 
> 
> 
>   
>   
> 
>   
> 
> When I use a classic FileAppender on my project everything work, but with
> my
> new appender I have nothing (I have changed the AssemblyInfo.cs file to
> use
> my new xml file). Can someone help me?
> 
> Thanks :)
> --
> View this message in context: http://old.nabble.com/My-custome-appender-
> does-not-work-tp28557313p28557313.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.

RE: My custome appender does not work

[Dominik Psenner]

You'll have to specify the assembly where it is contained. Usually this is
the project name, but if you take a look at your AssemblyInfo.cs you'll find
something like:

[assembly: AssemblyTitle("your.name.goes.here")]

Finally add that to the log4net configuration:

type="Alfaplan.Carola.Prototype.Logging.CustomeAppender;assembly=
your.name.goes.here"

At this point you're probably fine.

All information comes shipped without warranty, but if it works don't forget
to share your knowledge with others who need it. :-)

Greetings,
D.

> -Original Message-
> From: Nadesh [mailto:nadeshik...@hotmail.com]
> Sent: Friday, May 14, 2010 2:08 PM
> To: log4net-dev@logging.apache.org
> Subject: RE: My custome appender does not work
> 
> 
> Hi!
> 
> I have tried to instantiate the appender by code and it works this way!
> Thanks a lot :)! But do you have any idea why it does not work when I
> instantiate it in the xml file?
> 
> Bye
> 
> 
> Dominik Psenner wrote:
> >
> > Hi.
> >
> > May you wanna try to instantiate the appender by code to see if the
> > configuration is not used / wrong? I suspect that it can't find and
> > instantiate your class by
> > type="Alfaplan.Carola.Prototype.Logging.CustomeAppender".
> >
> > Greetings,
> > d.
> >
> >> -Original Message-
> >> From: Nadesh [mailto:nadeshik...@hotmail.com]
> >> Sent: Friday, May 14, 2010 11:49 AM
> >> To: log4net-dev@logging.apache.org
> >> Subject: My custome appender does not work
> >>
> >>
> >> Hello everyone!
> >>
> >> I have created a new custome appender which shows a box message:
> >>
> >> namespace Alfaplan.Carola.Prototype.Logging
> >> {
> >> class CustomeAppender : log4net.Appender.AppenderSkeleton
> >> {
> >>
> >> protected override void Append(log4net.Core.LoggingEvent
> >> loggingEvent)
> >> {
> >> MessageBox.Show("Message Sent: " +
> >> loggingEvent.RenderedMessage);
> >> }
> >> }
> >> }
> >>
> >> And an xml file which is used to launch the appender:
> >>
> >> 
> >>   
> >>  >> type="Alfaplan.Carola.Prototype.Logging.CustomeAppender">
> >>   
> >>   
> >>
> >>
> >>
> >>   
> >> 
> >>
> >> 
> >>   
> >>   
> >> 
> >>   
> >>
> >> When I use a classic FileAppender on my project everything work, but
> with
> >> my
> >> new appender I have nothing (I have changed the AssemblyInfo.cs file to
> >> use
> >> my new xml file). Can someone help me?
> >>
> >> Thanks :)
> >> --
> >> View this message in context: http://old.nabble.com/My-custome-
> appender-
> >> does-not-work-tp28557313p28557313.html
> >> Sent from the Log4net - Dev mailing list archive at Nabble.com.
> >
> >
> >
> >
> 
> --
> View this message in context: http://old.nabble.com/My-custome-appender-
> does-not-work-tp28557313p28558556.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.

RE: My custome appender does not work

[Dominik Psenner]

Sorry, I was wrong in my previous mail. Just thought a little and then
revisited one of the older projects of mine. The spacer is , instead of ;.
So this will work:

type="Alfaplan.Carola.Prototype.Logging.CustomeAppender,your.name.goes.here"

Lately I became too much of a WPF addicted. :-)


> -Original Message-
> From: Dominik Psenner [mailto:dpsen...@googlemail.com]
> Sent: Friday, May 14, 2010 2:29 PM
> To: 'Log4NET Dev'
> Subject: RE: My custome appender does not work
> 
> You'll have to specify the assembly where it is contained. Usually this is
> the project name, but if you take a look at your AssemblyInfo.cs you'll
> find something like:
> 
> [assembly: AssemblyTitle("your.name.goes.here")]
> 
> Finally add that to the log4net configuration:
> 
> type="Alfaplan.Carola.Prototype.Logging.CustomeAppender;assembly=
> your.name.goes.here"
> 
> At this point you're probably fine.
> 
> All information comes shipped without warranty, but if it works don't
> forget to share your knowledge with others who need it. :-)
> 
> Greetings,
> D.
> 
> > -Original Message-
> > From: Nadesh [mailto:nadeshik...@hotmail.com]
> > Sent: Friday, May 14, 2010 2:08 PM
> > To: log4net-dev@logging.apache.org
> > Subject: RE: My custome appender does not work
> >
> >
> > Hi!
> >
> > I have tried to instantiate the appender by code and it works this way!
> > Thanks a lot :)! But do you have any idea why it does not work when I
> > instantiate it in the xml file?
> >
> > Bye
> >
> >
> > Dominik Psenner wrote:
> > >
> > > Hi.
> > >
> > > May you wanna try to instantiate the appender by code to see if the
> > > configuration is not used / wrong? I suspect that it can't find and
> > > instantiate your class by
> > > type="Alfaplan.Carola.Prototype.Logging.CustomeAppender".
> > >
> > > Greetings,
> > > d.
> > >
> > >> -Original Message-
> > >> From: Nadesh [mailto:nadeshik...@hotmail.com]
> > >> Sent: Friday, May 14, 2010 11:49 AM
> > >> To: log4net-dev@logging.apache.org
> > >> Subject: My custome appender does not work
> > >>
> > >>
> > >> Hello everyone!
> > >>
> > >> I have created a new custome appender which shows a box message:
> > >>
> > >> namespace Alfaplan.Carola.Prototype.Logging
> > >> {
> > >> class CustomeAppender : log4net.Appender.AppenderSkeleton
> > >> {
> > >>
> > >> protected override void Append(log4net.Core.LoggingEvent
> > >> loggingEvent)
> > >> {
> > >> MessageBox.Show("Message Sent: " +
> > >> loggingEvent.RenderedMessage);
> > >> }
> > >> }
> > >> }
> > >>
> > >> And an xml file which is used to launch the appender:
> > >>
> > >> 
> > >>   
> > >>  > >> type="Alfaplan.Carola.Prototype.Logging.CustomeAppender">
> > >>   
> > >>   
> > >>
> > >>
> > >>
> > >>   
> > >> 
> > >>
> > >> 
> > >>   
> > >>   
> > >> 
> > >>   
> > >>
> > >> When I use a classic FileAppender on my project everything work, but
> > with
> > >> my
> > >> new appender I have nothing (I have changed the AssemblyInfo.cs file
> to
> > >> use
> > >> my new xml file). Can someone help me?
> > >>
> > >> Thanks :)
> > >> --
> > >> View this message in context: http://old.nabble.com/My-custome-
> > appender-
> > >> does-not-work-tp28557313p28557313.html
> > >> Sent from the Log4net - Dev mailing list archive at Nabble.com.
> > >
> > >
> > >
> > >
> >
> > --
> > View this message in context: http://old.nabble.com/My-custome-appender-
> > does-not-work-tp28557313p28558556.html
> > Sent from the Log4net - Dev mailing list archive at Nabble.com.

RE: My custome appender does not work

[Dominik Psenner]

This is a matter of design and cannot be generalized. Either way I always
prefer the multiple assemblies approach as it has some major advantages.
Just my two cents. Have a nice weekend.

> -Original Message-
> From: Nadesh [mailto:nadeshik...@hotmail.com]
> Sent: Friday, May 14, 2010 4:32 PM
> To: log4net-dev@logging.apache.org
> Subject: RE: My custome appender does not work
> 
> 
> Thank you Dominik :)! An other method which works is to declare the logger
> and the .xml file in the same project (they were in two different
> projects).
> It works too but I guess both methods are usefull depending on what we
> want
> to do ^^!
> 
> 
> Dominik Psenner wrote:
> >
> > Sorry, I was wrong in my previous mail. Just thought a little and then
> > revisited one of the older projects of mine. The spacer is , instead of
> ;.
> > So this will work:
> >
> >
> type="Alfaplan.Carola.Prototype.Logging.CustomeAppender,your.name.goes.her
> e"
> >
> > Lately I became too much of a WPF addicted. :-)
> >
> >
> >> -Original Message-
> >> From: Dominik Psenner [mailto:dpsen...@googlemail.com]
> >> Sent: Friday, May 14, 2010 2:29 PM
> >> To: 'Log4NET Dev'
> >> Subject: RE: My custome appender does not work
> >>
> >> You'll have to specify the assembly where it is contained. Usually this
> >> is
> >> the project name, but if you take a look at your AssemblyInfo.cs you'll
> >> find something like:
> >>
> >> [assembly: AssemblyTitle("your.name.goes.here")]
> >>
> >> Finally add that to the log4net configuration:
> >>
> >> type="Alfaplan.Carola.Prototype.Logging.CustomeAppender;assembly=
> >> your.name.goes.here"
> >>
> >> At this point you're probably fine.
> >>
> >> All information comes shipped without warranty, but if it works don't
> >> forget to share your knowledge with others who need it. :-)
> >>
> >> Greetings,
> >> D.
> >>
> >> > -Original Message-
> >> > From: Nadesh [mailto:nadeshik...@hotmail.com]
> >> > Sent: Friday, May 14, 2010 2:08 PM
> >> > To: log4net-dev@logging.apache.org
> >> > Subject: RE: My custome appender does not work
> >> >
> >> >
> >> > Hi!
> >> >
> >> > I have tried to instantiate the appender by code and it works this
> way!
> >> > Thanks a lot :)! But do you have any idea why it does not work when I
> >> > instantiate it in the xml file?
> >> >
> >> > Bye
> >> >
> >> >
> >> > Dominik Psenner wrote:
> >> > >
> >> > > Hi.
> >> > >
> >> > > May you wanna try to instantiate the appender by code to see if the
> >> > > configuration is not used / wrong? I suspect that it can't find and
> >> > > instantiate your class by
> >> > > type="Alfaplan.Carola.Prototype.Logging.CustomeAppender".
> >> > >
> >> > > Greetings,
> >> > > d.
> >> > >
> >> > >> -Original Message-
> >> > >> From: Nadesh [mailto:nadeshik...@hotmail.com]
> >> > >> Sent: Friday, May 14, 2010 11:49 AM
> >> > >> To: log4net-dev@logging.apache.org
> >> > >> Subject: My custome appender does not work
> >> > >>
> >> > >>
> >> > >> Hello everyone!
> >> > >>
> >> > >> I have created a new custome appender which shows a box message:
> >> > >>
> >> > >> namespace Alfaplan.Carola.Prototype.Logging
> >> > >> {
> >> > >> class CustomeAppender : log4net.Appender.AppenderSkeleton
> >> > >> {
> >> > >>
> >> > >> protected override void Append(log4net.Core.LoggingEvent
> >> > >> loggingEvent)
> >> > >> {
> >> > >> MessageBox.Show("Message Sent: " +
> >> > >> loggingEvent.RenderedMessage);
> >> > >> }
> >> > >> }
> >> > >> }
> >> > >>
> >> > >> And an xml file which is used to launch the appender:
> >> > >>
> >> > >> 
> >> > >>   
> >> > >>  >> > >> type="Alfaplan.Carola.Prototype.Logging.CustomeAppender">
> >> > >>   
> >> > >>   
> >> > >>
> >> > >>
> >> > >>
> >> > >>   
> >> > >> 
> >> > >>
> >> > >> 
> >> > >>   
> >> > >>   
> >> > >> 
> >> > >>   
> >> > >>
> >> > >> When I use a classic FileAppender on my project everything work,
> but
> >> > with
> >> > >> my
> >> > >> new appender I have nothing (I have changed the AssemblyInfo.cs
> file
> >> to
> >> > >> use
> >> > >> my new xml file). Can someone help me?
> >> > >>
> >> > >> Thanks :)
> >> > >> --
> >> > >> View this message in context: http://old.nabble.com/My-custome-
> >> > appender-
> >> > >> does-not-work-tp28557313p28557313.html
> >> > >> Sent from the Log4net - Dev mailing list archive at Nabble.com.
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> > --
> >> > View this message in context:
> >> http://old.nabble.com/My-custome-appender-
> >> > does-not-work-tp28557313p28558556.html
> >> > Sent from the Log4net - Dev mailing list archive at Nabble.com.
> >
> >
> >
> >
> 
> --
> View this message in context: http://old.nabble.com/My-custome-appender-
> does-not-work-tp28557313p28560178.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.

RE: Signed assemblies

[Dominik Psenner]

Howdie,

 

This nails down to the question: who's gonna pay the certificate? It would
probably require some kind of sponsorship to ASF that in turn will make sure
the log4net project gets the certificate. :-)

 

http://www.apache.org/foundation/sponsorship.html

 

Greetings,

D.

 

  _  

From: Damian Garbacz [mailto:dgarb...@future-processing.com] 
Sent: Friday, September 10, 2010 8:24 AM
To: log4net-dev@logging.apache.org
Subject: Signed assemblies

 

Hi,

I'm using log4net library in one of my projects (commercial application).

I'm trying to get the 'The Windows 7 Software' and 'Works with Windows
Server 2008 R2' Logo. One of the requirements is, that all assemblies should
be digital signed. Third party software should be signed by author. Is there
a possibility to get that kind of log4net library?

 

Please notice that signing tool used in Visual Studio is not sufficient.

There is a requirement, to use 'signtool.exe' application (described in

http://msdn.microsoft.com/en-us/library/8s9b9yaz(VS.80).aspx), along with
proper certificate (should be purchased in one of Microsoft trusted
providers e.g.  
http://www.verisign.com/index.html )

 

Best Regards

 

--

Damian Garbacz

Software Engineer & Team Leader

 

---

 Future Processing Sp. z o.o.

 Tel: +48 32 4612270

 Fax: +48 32 3762318

 Mob: +48 691 643356

   dgarb...@future-processing.com

   www.future-processing.com

---

 

RE: Signed assemblies

[Dominik Psenner]

Hi,

 

I am quite confident that if there were signed assemblies, they would be
available for download.

 

Greetings,

D.

 

  _  

From: Damian Garbacz [mailto:dgarb...@future-processing.com] 
Sent: Tuesday, September 14, 2010 10:09 AM
To: 'Log4NET Dev'
Subject: RE: Signed assemblies

 

Hello,

Because of order code of practice, before any sponsorship, a need an
official confirmation, that you already don't have that kind of certificate
and library.

Don't take this to negative, I just need that information, so I can go and
talk to my official supervisor.

 

Best regards.

 

--

Damian Garbacz

Software Engineer & Team Leader

 

---

 Future Processing Sp. z o.o.

 Tel: +48 32 4612270

 Fax: +48 32 3762318

 Mob: +48 691 643356

  <mailto:dgarb...@future-processing.com> dgarb...@future-processing.com

  <http://www.future-processing.com> www.future-processing.com

-----------

 

From: Dominik Psenner [mailto:dpsen...@gmail.com] 
Sent: Friday, September 10, 2010 10:56 AM
To: 'Log4NET Dev'
Subject: RE: Signed assemblies

 

Howdie,

 

This nails down to the question: who's gonna pay the certificate? It would
probably require some kind of sponsorship to ASF that in turn will make sure
the log4net project gets the certificate. :-)

 

 <http://www.apache.org/foundation/sponsorship.html>
http://www.apache.org/foundation/sponsorship.html

 

Greetings,

D.

 

  _  

From: Damian Garbacz [mailto:dgarb...@future-processing.com] 
Sent: Friday, September 10, 2010 8:24 AM
To: log4net-dev@logging.apache.org
Subject: Signed assemblies

 

Hi,

I'm using log4net library in one of my projects (commercial application).

I'm trying to get the 'The Windows 7 Software' and 'Works with Windows
Server 2008 R2' Logo. One of the requirements is, that all assemblies should
be digital signed. Third party software should be signed by author. Is there
a possibility to get that kind of log4net library?

 

Please notice that signing tool used in Visual Studio is not sufficient.

There is a requirement, to use 'signtool.exe' application (described in
<http://msdn.microsoft.com/en-us/library/8s9b9yaz(VS.80).aspx)>
http://msdn.microsoft.com/en-us/library/8s9b9yaz(VS.80).aspx), along with
proper certificate (should be purchased in one of Microsoft trusted
providers e.g.  <http://www.verisign.com/index.html>
http://www.verisign.com/index.html )

 

Best Regards

 

--

Damian Garbacz

Software Engineer & Team Leader

 

---

 Future Processing Sp. z o.o.

 Tel: +48 32 4612270

 Fax: +48 32 3762318

 Mob: +48 691 643356

  <mailto:dgarb...@future-processing.com> dgarb...@future-processing.com

  <http://www.future-processing.com> www.future-processing.com

---

 

Re: Query Precision Pattern Converter

[Dominik Psenner]

On 10/08/2010 06:46 PM, Dave Nay wrote:
> To improve the accuracy of our log messages in log4net, I went looking
> for a method to improve the date stamp.  I found that the NLog library
> has a formatter for adding a QueryPerformanceCounter to a log entry.
>  Not wanting to switch logging libraries, I converted their feature into
> a PatternConverter for log4net.  I have included the file here if anyone
> is interested in using it or merging it into log4net proper.
> 
> Also, are there any thoughts on if using a QPC is the proper method
> here, or if a System.Diagnostics.Stopwatch would be preferred?
> 
> Dave
> 
> -- 
> Dave Nay
> Senior Software Developer
> Mettler Toledo CI-Vision
> 

hi dave,

I just didn't get it out of your mail: what exactly does this thing do
and what should it do? from what I understood it just generates some
kind of numeric that will be added near the datetime of a log entry? why
wouldn't you print the CPU cycle there? I'm quite sure that would be
vastly faster than these string operations, which, from a first point of
view cost a significant amount of performance.

oh and, ahm, your code cant be merged into log4net as the licenses are
incompatible (see your header).

greetings,
d.



signature.asc
Description: OpenPGP digital signature

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

[Dominik Psenner]

This is a known problem that I already have mailed on the 5th february
2010 and was issued as LOG4NET-257
(https://issues.apache.org/jira/browse/LOG4NET-257). To quote Stefan
Bodewig:

==quote==
I ran the beta1 on NAnt 0.90 against log4net's build file in the root
dir of trunk and it worked without any problems. Anything specific I
should be looking out for?
==eof quote==

You may should consider to contact him.

Greetings,
Dominik

RE: suggestion for Log4Net 1.2.10

[Dominik Psenner]

Hi,

 

This is the exact same operation as the file mode does:

 

FileMode fileOpenMode = m_append ? FileMode.Append : FileMode.Create;

 

Hence this patch is completely useless. Parent directories are already
created:

if (!Directory.Exists(directoryFullName))
{
 
Directory.CreateDirectory(directoryFullName);
}

 

  _  

From: Pie Lee [mailto:haperk...@gmail.com] 
Sent: Wednesday, November 10, 2010 2:59 AM
To: log4net-dev@logging.apache.org
Subject: suggestion for Log4Net 1.2.10

 

 Hi, ALL

Find that if the rolling file path do not exist, the appender will do
nothing (you will get confused what is wrong..)

I think it had better create the corresponding directory and file.

So I change the code at Log4net--Appender--FileAppender.cs

public override Stream AcquireLock()
{
if (m_stream==null)
{
try
{
 
using(CurrentAppender.SecurityContext.Impersonate(this))
{
// Ensure that the directory structure exists
string directoryFullName =
Path.GetDirectoryName(m_filename);

// Only create the directory if it does not
exist
// doing this check here resolves some
permissions failures
if (!Directory.Exists(directoryFullName))
{
 
Directory.CreateDirectory(directoryFullName);
}
 
//added by me
if (!System.IO.File.Exists(m_filename))
{
System.IO.File.Create(m_filename).Close();
}

FileMode fileOpenMode = m_append ?
FileMode.Append : FileMode.Create;
m_stream = new FileStream(m_filename,
fileOpenMode, FileAccess.Write, FileShare.Read);
m_append=true;
}
}
catch (Exception e1)
{
CurrentAppender.ErrorHandler.Error("Unable to
acquire lock on file "+m_filename+". "+e1.Message);
}
}
return m_stream;
}


The benefit is that anyone who uses log4net will feel convenient

Re: Shared log4net config file for multiple programs

[Dominik Psenner]

Hi,

you could load the configuration from file and alter it in each
program so that it fits your requirements. You have full access to the
log4net logging system also in code.

regards & happy new year,
d.

2010/12/27 kshah82 :
> Hi, Currently we are having 2 programs which are using centralized log4net
> config resided at some location like "C:". Now the no. of programs can be
> increased later on 20 to 25. Now, we want that we should be able to set
> severity level for each program independeltly without creating separate
> appender for each of them . How can we achieve this ? We know that for each
> of program we can create separate appender and reference it on individual
> logger(which is based on each service) to achieve this. Bus is there any
> other way around ?
> 
> View this message in context: Shared log4net config file for multiple
> programs
> Sent from the Log4net - Dev mailing list archive at Nabble.com.
>



-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

RE: Issue with rolling based on date

[Dominik Psenner]

It would be easier to log into different files for each process.

I didn't take a look at the source, but I believe that the rolling file
appender lacks a cross-process lock mutex due to performance reasons (i.e.
on my computer it takes ~12ms to acquire a file based mutex).

> -Original Message-
> From: kshah82 [mailto:kinnar_s...@persistent.co.in]
> Sent: Tuesday, February 15, 2011 3:01 PM
> To: log4net-dev@logging.apache.org
> Subject: Issue with rolling based on date
> 
> 
> Hi,
> 
> We are having 10 programs which are rolling into same log file namlely
> "logger.log".
> 
> Below is configuration of RollingFileAppender which we are using :
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> Our rolling based on date is running at every 12 hour span means at 12
> Noon
> and 12 Midnight. Now what is happening when multiple programs try to log
> into log file at the same time when rolling happens means at 12
> noon/midnight, then size of file getting rolled is becoming very small
> compare to original file size(i.e Suppose logger.log is around 1 MB at 12
> noon, when rolling happens the new rolled file which is get generated is
> around 3 KB or somewhat). So, almost data get lost due to this. This is
> basically happening when multiple programs try to log into log file at the
> same time of when rolling happens(means at 12 noon/midnight).
> 
> Please revert back to us on this ASAP as its very important us to go
> ahead.
> --
> View this message in context: http://old.nabble.com/Issue-with-rolling-
> based-on-date-tp30931115p30931115.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.

RE: Issue with rolling based on date

[Dominik Psenner]

Have you tried to debug it and file a bug including a nice trace? Here's the
source:

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

> -Original Message-
> From: kshah82 [mailto:kinnar_s...@persistent.co.in]
> Sent: Thursday, February 17, 2011 2:30 PM
> To: log4net-dev@logging.apache.org
> Subject: RE: Issue with rolling based on date
> 
> 
> Hi Douglas,
> Sorry , my exmaple configuration does not having minimallock property
> specified. But in my application, I am already using Minimallock property.
> But my main problem is that when rolling based on date happens, the size
> of
> new rolled file gets generated out of original log file is very very
> small.
> I want a help in that area. Any help would be highly appreciated.
> 
> Regards,
> Kinnar
> 
> 
> kshah82 wrote:
> >
> > Hi Douglas,
> >
> > Thanks for your feedback. If you see my rollingfileappender
> configuration,
> > then i am already using Minimallock setting. But my main problem is that
> > when rolling based on date happens, the size of new rolled file gets
> > generated out of original log file is very very small. I want a help in
> > that area. Any help would be highly appreciated.
> >
> > Regards,
> > Kinnar
> >
> > Douglas E Wegscheid wrote:
> >>
> >> duh. sorry. log4net, not log4j
> >>
> >> | DOUGLAS E. WEGSCHEID // LEAD ENGINEER
> >> (269) 923-5278 // douglas_e_wegsch...@whirlpool.com
> >> "A wrong note played hesitatingly is a wrong note. A wrong note played
> >> with conviction is interpretation."
> >>
> >>
> >>
> >> Douglas E Wegscheid 
> >> 02/16/2011 02:48 PM
> >> Please respond to
> >> "Log4NET Dev" 
> >>
> >>
> >> To
> >> "Log4NET Dev" 
> >> cc
> >>
> >> Subject
> >> RE: Issue with rolling based on date
> >>
> >>
> >>
> >>
> >>
> >>
> >> it's in the log4j 1.2 FAQ:
> >>
> >> 24. How do I get multiple process to log to the same file?
> >>
> >>
> >>
> >> -Kinnar Shah  wrote: -
> >>
> >> To: Dominik Psenner , 'Log4NET Dev'
> >> 
> >> From: Kinnar Shah 
> >> Date: 02/16/2011 08:06AM
> >> cc: Taraka Ravi , Yash Ganthe
> >> , Manish Gupta
> >> 
> >> Subject: RE: Issue with rolling based on date
> >>
> >> Hi Dominik,
> >>
> >> Thanks for your feedback. But logging into single file by multiple
> >> programs is our primary requirement. Can you please provide any work
> >> around for this ?
> >>
> >> Regards,
> >> Kinnar
> >>
> >> -Original Message-
> >> From: Dominik Psenner [mailto:dpsen...@gmail.com]
> >> Sent: Wednesday, February 16, 2011 6:20 PM
> >> To: 'Log4NET Dev'
> >> Cc: Kinnar Shah
> >> Subject: RE: Issue with rolling based on date
> >>
> >> It would be easier to log into different files for each process.
> >>
> >> I didn't take a look at the source, but I believe that the rolling file
> >> appender lacks a cross-process lock mutex due to performance reasons
> >> (i.e.
> >> on my computer it takes ~12ms to acquire a file based mutex).
> >>
> >>> -Original Message-
> >>> From: kshah82 [mailto:kinnar_s...@persistent.co.in]
> >>> Sent: Tuesday, February 15, 2011 3:01 PM
> >>> To: log4net-dev@logging.apache.org
> >>> Subject: Issue with rolling based on date
> >>>
> >>>
> >>> Hi,
> >>>
> >>> We are having 10 programs which are rolling into same log file namlely
> >>> "logger.log".
> >>>
> >>> Below is configuration of RollingFileAppender which we are using :
> >>>type="log4net.Appender.RollingFileAppender">
> >>> 
> >>> 
> >>>
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>> 
> >>>   
> >>>
> >>> Our rolling based on date is running at every 12 hour span means at 12
> >>> Noon
> >>> and 12 Midnight. Now what is happening when multiple programs try to
> log
> >

RE: [jira] [Updated] (LOG4NET-290) Add Lambda-based ILog-Extensions (embedded log.IsEnabled)

[Dominik Psenner]

Did you compare runtime performance of the 'if syntax' versus the 'method
invoke syntax'?

> -Original Message-
> From: Lars Corneliussen (JIRA) [mailto:j...@apache.org]
> Sent: Tuesday, April 05, 2011 9:00 AM
> To: log4net-dev@logging.apache.org
> Subject: [jira] [Updated] (LOG4NET-290) Add Lambda-based ILog-Extensions
> (embedded log.IsEnabled)
> 
> 
>  [ https://issues.apache.org/jira/browse/LOG4NET-
> 290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Lars Corneliussen updated LOG4NET-290:
> --
> 
> Description:
> This statement:
> if (log.IsDebugEnabled) log.DebugFormat("x: {0}", 123)
> 
> Could be nicely shortened to:
> log.Debug( m=>m("value= {0}", obj.Value) );
> 
> I'm already apache committer (NPanday Incubator Project) and would be
> happy to help with this interface. The simplest thing would be to offer it
> as static Extension-Methods to ILog.
> 
>   was:
> {code}
> if (log.IsDebugEnabled) log.DebugFormat("x: {0}", 123)
> {code}
> 
> Could be nicely shortened to:
> {code}
>   log.Debug( m=>m("value= {0}", obj.Value) );
> {code}
> 
> I'm already apache committer (NPanday Incubator Project) and would be
> happy to help with this interface. The simplest thing would be to offer it
> as static Extension-Methods to ILog.
> 
> 
> > Add Lambda-based ILog-Extensions (embedded log.IsEnabled)
> > -
> >
> > Key: LOG4NET-290
> > URL: https://issues.apache.org/jira/browse/LOG4NET-290
> > Project: Log4net
> >  Issue Type: New Feature
> >  Components: Core
> >Affects Versions: 1.2.10
> >Reporter: Lars Corneliussen
> > Fix For: 1.2.11
> >
> >
> > This statement:
> > if (log.IsDebugEnabled) log.DebugFormat("x: {0}", 123)
> > Could be nicely shortened to:
> > log.Debug( m=>m("value= {0}", obj.Value) );
> > I'm already apache committer (NPanday Incubator Project) and would be
> happy to help with this interface. The simplest thing would be to offer it
> as static Extension-Methods to ILog.
> 
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: Log4net Asynchronous Logging

[Dominik Psenner]

Howdie,

would you please be more specific? What should be asynchronous?

Greetings,
D.

> -Original Message-
> From: anjansingh [mailto:mailan...@hotmail.com]
> Sent: Monday, April 11, 2011 7:35 AM
> To: log4net-dev@logging.apache.org
> Subject: Log4net Asynchronous Logging
> 
> 
> Hi All,
> 
> Can anybody plz give me code walkthru of how to do a Asynchronous logging
> using Log4net? I have been searching for sometime but cound not get any
> helpful link. Any useful help would do the needful. Urgent help needed.
> --
> View this message in context: http://old.nabble.com/Log4net-Asynchronous-
> Logging-tp31367440p31367440.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.

RE: Log4net Asynchronous Logging

[Dominik Psenner]

This would mean you have to implement your (database) appender if there's
none for the kind of database you have and configure the application logs to
use that appender.

> -Original Message-
> From: anjansingh [mailto:mailan...@hotmail.com]
> Sent: Monday, April 11, 2011 11:10 AM
> To: log4net-dev@logging.apache.org
> Subject: RE: Log4net Asynchronous Logging
> 
> 
> Thanks for yoyr reply. Actually I am going to build and application in
> ASP.NET that requires logging of exceptions in SQL Server. For that
> purpose
> I need to log exception details in database asynchronously.
> 
> Dominik Psenner wrote:
> >
> > Howdie,
> >
> > would you please be more specific? What should be asynchronous?
> >
> > Greetings,
> > D.
> >
> >> -Original Message-
> >> From: anjansingh [mailto:mailan...@hotmail.com]
> >> Sent: Monday, April 11, 2011 7:35 AM
> >> To: log4net-dev@logging.apache.org
> >> Subject: Log4net Asynchronous Logging
> >>
> >>
> >> Hi All,
> >>
> >> Can anybody plz give me code walkthru of how to do a Asynchronous
> logging
> >> using Log4net? I have been searching for sometime but cound not get any
> >> helpful link. Any useful help would do the needful. Urgent help needed.
> >> --
> >> View this message in context: http://old.nabble.com/Log4net-
> Asynchronous-
> >> Logging-tp31367440p31367440.html
> >> Sent from the Log4net - Dev mailing list archive at Nabble.com.
> >
> >
> >
> >
> 
> --
> View this message in context: http://old.nabble.com/Log4net-Asynchronous-
> Logging-tp31367440p31368437.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.

Re: System.FormatException: Index (zero based) must be greater than or equal to zero

[Dominik Psenner]

On 05/31/2011 06:46 PM, mc_line wrote:
> 
> 
> Anyone has any idea?
> 
> 
> Some help needed here


You may should take a look at your format string.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/12/2011 07:19 PM, Stefan Bodewig wrote:
> Short term we'll be slowed down by the fact that there are only very few
> people with write access to the source tree, of course.

Could the short term development be done in a remote repository,
likewise hg hosted on bitbucket? One would not need to have write access
to the original source and can still work versioned. If one keeps a
strict linear history (no merges), one should also be able to push
changes back to the svn repository.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/12/2011 10:30 PM, Dominik Psenner wrote:
> On 08/12/2011 07:19 PM, Stefan Bodewig wrote:
>> Short term we'll be slowed down by the fact that there are only very few
>> people with write access to the source tree, of course.
> 
> Could the short term development be done in a remote repository,
> likewise hg hosted on bitbucket? One would not need to have write access
> to the original source and can still work versioned. If one keeps a
> strict linear history (no merges), one should also be able to push
> changes back to the svn repository.

I actually just cloned the apache svn and am currently pushing the
changes to a bitbucket repository here:

https://bitbucket.org/NachbarsLumpi/log4net

The operation could take some time. Once it is done, there should be 553
changesets. The last would be:

changeset:   553:7f145743e63e
tag: tip
user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
date:Wed Oct 13 03:26:57 2010 +
summary: Additional fix for LOG4NET-59 to ensure correct call to
System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

Best regards
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/12/2011 10:46 PM, Dominik Psenner wrote:
> I actually just cloned the apache svn and am currently pushing the
> changes to a bitbucket repository here:
> 
> https://bitbucket.org/NachbarsLumpi/log4net

FWIW, I managed to apply some of the patches that were submitted into a
fork of the just created log4net clone:

https://bitbucket.org/NachbarsLumpi/log4net-patches/changesets

For now they're just placed on top of the svn revisions that those
patches apply to. For each of them we have to:

 * see if the patches are not fixed already
 * see if they fit into the current latest tip (trunk)
 * revise if they include sane changes
 * determine if they should be included in the upcoming release

Best regards
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/13/2011 06:30 AM, Stefan Bodewig wrote:
> We do have a read-only git version at git://git.apache.org/log4net.git
>  mirrored at github as well
> 

Didn't know that. :-) Since that repository is read-only, it is not
exactly a great help for whoever wants to hack on log4net now.

> 
> Given that svn is new to some of the people who raised their hand to
> help I'm a bit reluctant to add yet another tool new to them to the mix
> (and throw in something like git-svn or hg-svn on top of that).  Combine
> that with the change in philosophy a distributed VCS brings.

If they're new to svn, it would actually be no great effort to learn
another tool.

> 
> I agree this would work and would be willing to give it a try with
> people who want to work that way.  But this really depends on the people
> who will actually do the commit to svn (which I currently can't do
> myself either).

Who are those people? Maybe they should comment on this?



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/13/2011 06:34 AM, Stefan Bodewig wrote:
>> For each of them we have to:
>>  * see if the patches are not fixed already
>>  * see if they fit into the current latest tip (trunk)
>>  * revise if they include sane changes
>>  * determine if they should be included in the upcoming release
> 
> If you do any of these, could you note it as a comment inside the
> corresponding JIRA tickets?  This would reduce the chance of people
> duplicating work.

Sure thing. Can we place some other comments somewhere so that others
can find out that there's a repository they could actually work on?

I'm afraid I don't have the time to actually hack on log4net. But I
could help with what I'm good at: lever some of the major data migration
work to smooth the way for others that need a repository.



signature.asc
Description: OpenPGP digital signature

Discussing the existing patches

[Dominik Psenner]

Can we start a discussion on the existing patches? Primary targets of
discussion are the ones I applied here:

https://bitbucket.org/NachbarsLumpi/log4net-patches/

This includes the unresolved issues containing a patch file:
* LOG4NET-190
* LOG4NET-108
* LOG4NET-270
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Open issues for 1.2.10 release

[Dominik Psenner]

There are 9 open issues targeted for 1.2.10. They should probably be
rescheduled to be included in 1.2.11?

This list includes:

* LOG4NET-285
* LOG4NET-274
* LOG4NET-227
* LOG4NET-221
* LOG4NET-211
* LOG4NET-258
* LOG4NET-235
* LOG4NET-236
* LOG4NET-237

Please discuss.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

Hi Stefan and Roy,

sorry for the late response. This sunny sunday took me for a trip into
the mountains. :-) See the inlines below.

> The normal state of an ASF project is that all people who contribute
> code on a regular basis have write access - if they want it.

I would not advise to commit to the ASF SVN repository directly. Changes
put into SVN are carved into stone and immutable FOREVER. Mercurial
allows a more flexible way for working on things. Just read this mail to
the end to get there. :-)

I know this may be a bit much information and it could feel like "uoh,
what the heck does this guy mean - do I have to learn all these
things?", but it's not really complicated and the learning curve should
be exponential. So I get straight to the next topic:

> But once the people who would be working "in connected mode" in a
> distributed VCS have been doing it for long enough that the existing
> committers have gained enough trust the whole thing won't be necessary
> any longer.  The people who stick around long enough will get write
> access to svn sooner or later.

The main goal is to keep the SVN trunk stable and safe in every
revision. Since the SVN repository history is immutable, this means that
only revised and "good" patches are put there.

Therefore I would like to propose a different workflow that works just
great when working in a team. Think of "log4net", "log4net-crew" and
"log4net-developer" as repositories. The "log4net-developer" repository
will actually exist for every developer and maybe even multiple times if
one developer works on more than one issue. The flow of data is basically:

log4net <--> log4net-crew --> log4net-developer
   ^ |
   | v
  apply patch <--  discuss patch

What does that mean for us? Each developer has a local clone
(log4net-developer) of the repository log4net-crew and works on that
clone to fix an issue. The changesets produced there can then be
discussed by other developers and once - let's say - more than half of
the developers agree on how things are done, the patch is applied to
log4net-crew and subsequently put back into the log4net SVN @ apache.

You may ask yourself how we can discuss on a changeset if the others
don't know about it? Mercurial offers some very convenient ways to share
information between developers. One is to publish the information in a
repository so that others can pull that information into their local
clone (that's how mercurial works after all) or the other way would be
to mail a patch to this list so that others can import it and comment on it.

One could export a patch and then send it manually to this list:

$ hg export rev > patch.diff

Or he can use the patchbomb extension that does exactly this in a oneliner:

$ hg email rev

Now other developers can import the patch manually:

$ hg import patch.diff

or use again an extension called Mbox that does the reverse operation of
Patchbomb in a oneliner:

$ hg mimport

Finally the other developer revises the changesets and provides feedback
on the mailing list. Once every on agrees it is really easy to put the
changes to the log4net-crew repository:

$ hg push log4net-crew

And from the crew repository, whoever has write privileges on the svn,
can do:

$ hg pull log4net-crew
$ hg push log4net

Obviously I stripped some information on how one has to set up things,
but rest assured that I'm going to provide that information if you ask
for it.

Last but not least I want to mention some useful links. The most
interesting things should be written down here (without the chapter
about Fabric):

http://www.satchmoproject.com/blog/2010/feb/27/satchmo-workflow/

and more general information on mercurial can be found here:

http://mercurial.selenic.com/wiki/QuickStart

But that wiki contains also more information. For example the
installation and usage of extensions that this kind of workflow need are
well documented there:

http://mercurial.selenic.com/wiki/RebaseExtension
http://mercurial.selenic.com/wiki/MqExtension
http://mercurial.selenic.com/wiki/MboxExtension
http://mercurial.selenic.com/wiki/PatchbombExtension

And there's a more than useful windows client called TortoiseHG
(http://tortoisehg.bitbucket.org/) that eases the commandline hacking
with a nice userinterface (even mq, patchbomb and other things).

Feel free to ask if you feel you need to!

> The normal process is that a committer resolves the JIRA issue once the
> code is in svn.  Sometimes the user who opened the issue will close it
> after the fix has been verified but this is truely optional.

Yes. Right now we can only comment on issues, which is obviously not
enough to be productive. We should contact some people @ JIRA so that at
least one of us gets write privileges to the repository and
administrative privileges to the bugtracker ASAP.

Best regards,
D.



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

I forgot to say that this workflow works just great even for the time we
have no write privileges on the SVN repository. The changesets will be
stuck at "log4net-crew", waiting there to be pushed to the svn repository.

Best regards
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Discussing the existing patches

[Dominik Psenner]

On 08/13/2011 04:58 PM, Stefan Bodewig wrote:
> Absolutely.  I'm running out of time right now, but will focus on the
> three issues you've mentioned soon.

Great!

Here there are the patches:
https://bitbucket.org/NachbarsLumpi/log4net-patches

You can review them by enabling the patchqueue extension in your
mercurial configuration and then do:

$ hg qclone ssh://h...@bitbucket.org/NachbarsLumpi/log4net-patches

At this point you have cloned the repository containing the patch queue.
This means you have the complete history of log4net:

$ hg log -l 1
changeset:   553:7f145743e63e
tag: tip
user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
date:Wed Oct 13 03:26:57 2010 +
summary: Additional fix for LOG4NET-59 to ensure correct call to
System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

and a hidden repository containing a versioned history of some patches.
To see which patches you got, you can do a:

$ hg qseries
LOG4NET-190
LOG4NET-108
LOG4NET-235
LOG4NET-271
LOG4NET-270

To apply a patch onto your working revision, you just have to:

$ hg qpush LOG4NET-190

Which will literally "create" a commit containing the patch information:

$ hg log -l 2
changeset:   554:200e5c7be470
tag: LOG4NET-190
tag: qbase
tag: qtip
tag:     tip
user:Dominik Psenner 
date:Sun Aug 14 23:28:05 2011 +0200
summary: LOG4NET-190

changeset:   553:7f145743e63e
tag: qparent
user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
date:Wed Oct 13 03:26:57 2010 +
summary: Additional fix for LOG4NET-59 to ensure correct call to
System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

At this point you can take a look at the patch, test the impact and once
you're done with it, you can unapply the patch by doing:

$ hg qpop

which brings you back:

$ hg log -l 1
changeset:   553:7f145743e63e
tag: tip
user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
date:Wed Oct 13 03:26:57 2010 +
summary: Additional fix for LOG4NET-59 to ensure correct call to
System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

If you wanted to modify a patch, you could push a patch with:

$ hg qpush LOG4NET-190
$ "hack hack hack"

Update the patch file:

$ hg qrefresh

And commit the changes you made to that patch file:

$ hg commit --mq

And finally push the changes you made to the patch repository:

$ hg push --mq

You can iterate over these steps as often as you want and work on a
patch as long as it takes to finish it in perfection without actually
modifying the project history itself. Of course one day the patch will
be finished and I would like to show you the steps you would take then.

First of all you apply the patch as before:

$ hg qpush LOG4NET-190

Then you finish it:

$ hg qfinish LOG4NET-190

Which does remove the patch from the series:

$ hg qseries
LOG4NET-108
LOG4NET-235
LOG4NET-271
LOG4NET-270

At this point we commit the changes made in the patch repository:

$ hg commit --mq -m'finished LOG4NET-190'

And push that information to the patch repository at bitbucket:

$ hg push --mq

What we have now in the project history is the newly added commit record
of the patch we made:

$ hg log -l 2
changeset:   554:200e5c7be470
tag: tip
user:Dominik Psenner 
date:Sun Aug 14 23:28:05 2011 +0200
summary: LOG4NET-190

changeset:   553:7f145743e63e
user:rgrabowski@13f79535-47bb-0310-9956-ffa450edef68
date:Wed Oct 13 03:26:57 2010 +
summary: Additional fix for LOG4NET-59 to ensure correct call to
System.IO.File.GetLastWriteTime or GetLastWriteTimeUtc

And since the crew are surely interested in the work you've finished,
you do this to push the information to the log4net-crew repository:

$ hg push

This is how one works with patch queues! :-) At this point I could pull
the change in the crew repository by doing:

$ hg pull

and push that information to svn if I had write privileges.

Feel free to ask questions if there are any!
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Open issues for 1.2.10 release

[Dominik Psenner]

On 08/13/2011 04:46 PM, Stefan Bodewig wrote:
> I'm not even sure whether some of them still are relevant.  They
> certainly need to be rescheduled.
> 
> My preference would be to have some release like 1.2.MAINTNENANCE that
> we'd assign things to that may eventually get fixed in a 1.2.x release
> if we agree that these are the versions that actually work for compact
> framework and 1.x - and a few others similar unspecific releases.
> 
> We then pick the pieces from there as we prepare real releases.
> 
> Right now I'm afraid we'll have to visit all open issues and
> re-assign/close them.

Its a lot of work, but it has to be done. We're then able to identify
(really) open bugs and we can then see forward to resolve them for 1.2.11.

Further there are a lot of changesets (101) that are still waiting to be
included in the next release. We probably have to work through them too.

The other big story is the support for the .NET client profiles. As I
understood it, we have to drop everything in log4net that is not
supported in a .NET 4.0 client profile (i.e. references to System.Web).
To achieve this we have at least two options:

1] refactor everything that doesn't fit with the client profile into a
separate project / dll
2] maintain a .net 4.0 client profile branch with a subset of the
log4net functionality

* Solution [1] is a pain for everyone that uses log4net since they need
to reference two libraries instead of one
* Solution [2] is a pain to maintain with subversion

We have to investigate into all this a little more so that we can come
up with a plan that just works.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/15/2011 07:26 AM, Stefan Bodewig wrote:
> I think it is important for us all, that we do have a single place with
> the code to discuss - and once we have enough people with write access
> it won't be necessary to think about any other place than svn for this.
> 
> The "hg or git clone of svn" model works very well for the odd case of
> people who want to contribute larger patches but don't have write access
> themselves - which should be the exception.

And it makes sense in cases where people work together on a bugfix
without the need of spamming the svn log with stuff that doesn't work.
Right now the most useful log4net that people use is the svn trunk. We
shouldn't break it!

Indeed the history how a single patch evolves is not at ASF, but since
patches should be sent to the mailing list (patchbomb extension) and
discussed there (mbox extension) it is not that far from ASF at all.

Please correct me if I'm wrong.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Client Profiles (was Re: Open issues for 1.2.10 release)

[Dominik Psenner]

On 08/15/2011 08:29 AM, Stefan Bodewig wrote:
> Right now the NAnt build builds several different assemblies targeting
> different platforms all out of the same source tree and it should be
> straight forward to extend that to the client profile as well.
> 
> Tasos' patch basically works the same way as log4net supports the
> compact framework now - it adds a conditional compilation symbol and
> simply excludes all System.Web stuff if that is set.

I get the idea. Until now I didn't understand how log4net was built at
all. If it works, it's fine by me. :-)

> The main hurdle may be NAnt's limited support for .NET 4.0 (need to use
> a nightly build for now) and I don't think there is a target defintion
> for client profiles at all - but that should be doable.  I'm willing to
> invest some effort here.

What I've read so far, NAnt 0.91 alpha 2 supports .NET 4.0. At least
that's what they're writing in that table on their frontpage
(http://nant.sourceforge.net/). Does that help us?

> Longer term switching to MSBuild or the solution task in NAnt and using
> Visual Studio 2010 solution files targeting the correct platform may
> work should we plan to drop support form 1.x, Compact Framework and
> explicit support for Mono.

I would favorise that, but I don't know if that's possible with ASFs
continuous integration.

> What I wonder is: do we really need 3.5 and 4.0 assemblies at all?
> Wouldn't a 2.0 assembly including System.Web and a 3.5 client profile
> assembly without it work for .NET 3.5/4.0 projects and and their client
> profile subsets well enough?  For 1.2.11 that is, later we may want to
> use LINQ or WCF or whatever.

Yes, it should. That's also one thing I wanted to try. If MSbuild can
produce something that works for .NET 3.5/4.0 client profile and .NET
4.0 we may be able to reproduce it with NAnt. Otherwise we don't even
have to try, do we?
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Client Profiles

[Dominik Psenner]

On 08/15/2011 11:26 AM, Stefan Bodewig wrote:
> Like I said later, I'm not convinced we need to target 4.0 at all as the
> 2.0 version should just work.  For client profile we could use a
> stripped down 2.0 version or explicitly target 3.5 (client profile).
> But I may very well be missing some nuance.

You once asked if VS2010 can change the target profile. Yes, it can. I
did it at work some time. But unfortunatly it is something that defines
a projects dependencies. So it is not something that can simply be
changed by a built tool. In VS2010 you have to configure the project to
be targeted for a specific .NET framework and VS makes sure the project
finds the correct libraries.

> We don't have any (working) CI for log4net right now.  The only one I'm
> aware of is Gump and this one only builds the Mono parts so isn't really
> useful.  It doesn't perform any tests either.

*ouch*

Now that you say it. I just ran nant from my ubuntu laptop and was
impressed that it went through without complains. :-) I just built
log4net for mono 1.0 and 2.0. *laughing* I'm going to copy that dll to
my windows pc and see if I can use it across different projects (2.0,
3.0, 3.5, 4.0, 3.5CP, 4.0CP) and report the results.

> Jenkins - one option available from ci.apache.org - does support MSBuild
> (on Windows, of course) and likely NAnt as well.  I know the Lucene.NET
> project is looking for CI builds so the infrstructure for "real" .NET
> builds should be there at one point.

Where did you read up jenkins? There's continuum and buildbot. The
latter runs on a win7 machine and therefore could be able to run msbuild.

Btw, why does the nant build only produce mono files?
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Moving forward with updates, builds and versions

[Dominik Psenner]

On 08/15/2011 11:39 AM, Stefan Bodewig wrote:
> If we get back on track with regular releases the occasional trunk
> breakage will be OK as people won't be forced to use arbitrary trunk
> revisions.

No, it is not OK at all. IMHO every recorded history should be a
monolithic working library. Only if you do that you make sure that every
release is just fine because if you don't, people will make errors and
people will forget some thing or the other.

"Ok, I'm done with it, for now I commit it and tomorrow I'll fix the
special case".

If patches don't get revised, it results exactly in the situation we
have in log4net right now:

101 revisions since the last release and nobody knows whether those
"fixes" do really fix the issues or those revisions are safe to include
in the next release because there are no unit tests. I don't think
that's funny.

If there's the risk that your logging dll crashes a software responsible
to do your money transfers just because some patch was included that
shouldn't have been, the fun ends for sure.

Well, maybe I'm overdoing it a little but IMHO a library that is well
spread should be developed "safe".

>> Indeed the history how a single patch evolves is not at ASF, but since
>> patches should be sent to the mailing list
> 
> Nope. JIRA.

Then the medium to transfer a patch is JIRA and not the mailing list.
Doesn't change much, does it? :-)
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

RE: Planning 1.2.11

[Dominik Psenner]

>this is how I think we could get to a 1.2.11 release in the timeframe of
>about a month

Looks fine, no objections.

>If the people who want to help out can create JIRA acounts and tell me
>their login id I can add you to this group and we'll see which
>permissions this will grant you.

I'm quite busy this week and just as you Stefan, I'm going to part for
holidays tomorrow. This means I probably won't touch a keyboard for the next
two weeks. That is, it will largely depend on the weather forecasts. :-)

Here's my id anyway: nachbarslumpi

RE: Planning 1.2.11

[Dominik Psenner]

>I've managed to get NAnt 0.91apha2 working after some hassles, I hope to
>be able to build assemblies targeting 4.0 by tommorow.

That's great news! I ran out of luck the last time I tried it, but I'm quite
unused to NAnt anyway. So that could have been the reason. ;-)

Best regards,
D.

RE: Name for MutexLock?

[Dominik Psenner]

>LOG4NET-164 introduced a new locking strategy for FileAppender which
>technically uses a System.Threading.Mutex with a name built from the log
>file's name.  This should allow separate processes to share a log file
>without repeatedly opening and closing it.
>
>The main remaining issue is its name (apart from docs which will follow
>once the name is settled).  Right now it is called MutexLock but that
>may not convey to users what this actually does - they'd need to know
>what a Mutex is in the first place.
>
>I'm notoriously bad at names so I'm asking here now.  Names suggested in
>the JIRA ticket are "InterProcessLock", "SystemWideLock" and
>"GlobalLock".

Are we talking about the variable name? In that case I would prefer a name
that makes it obvious what it is behind:

MutexLock

:-)

Did you actually do performance tests too? A mutex is rather expensive and
it should be avoided to acquire/release it multiple times unless really
necessary.

Greetings,
D.

RE: Name for MutexLock?

[Dominik Psenner]

>Not only, it would also appear inside the config file in order to set
>the locking model of FileAppender like in the third example of
>http://logging.apache.org/log4net/release/config-examples.html#fileappender
>Right now it would be
>
>

Quite obvious what it does. If one enters "MutexLock .NET" into google there
are plenty useful resources to find out what it does.

>> Did you actually do performance tests too? A mutex is rather expensive
>and
>> it should be avoided to acquire/release it multiple times unless really
>> necessary.
>
>It would be aquired and released for each single logging event.  The
>alternatives are (1) don't share the same log file between different
>processes or (2) repeatedly open and close the file (which is the
>MinimalLocking model).  Whether the mutex performs better or worse than
>MinimalLocking depends on the concrete circumstances, I guess, but I'd
>expect the overhead of opening a file to be significant as well.

Based on my observations, acquiring a mutex lock can take up to 30ms. IMHO
the solution alternative 3) would require a little more effort. Namely
collect a bunch of log events in the appender and dispatch them with one
Mutex lock as fast as possible. I've here a reference implementation, but
unfortunately I can't share it due to license restrictions. :-(

The implementation basically works on two queues containing a ordered set of
log events:

* outerQueue
* innerQueue

New events are put to the outerQueue and all items in the innerQueue are
written to the logfile in one go. And to speed things up, the queues are
swapped in two conditions:

* new log event is put to the outerQueue and the innerQueue is empty
  => swap innerQueue and outerQueue and write all events in innerQueue
* innerQueue write is finished and the outerQueue is not empty
  => swap innerQueue and outerQueue and write all events in innerQueue

I tested this on a quad-core, running 8 processes with 8 threads each
logging in a while(true) loop and it works like a charm. :-)

Greetings,
D.

RE: Name for MutexLock?

[Dominik Psenner]

Remoting appender:

If the application goes down that's finally persisting the log events, the
logging is down too.

 

InterProcessLock / MutexLock:

Since every application persists the log events by itself, the logging
survives as long as the application is "alive".

 

  _  

From: Ron Grabowski [mailto:rongrabow...@yahoo.com] 
Sent: Wednesday, September 14, 2011 12:44 AM
To: Log4NET Dev
Subject: Re: Name for MutexLock?

 

Can you share a config snippet showing how to use the RemotingAppender like
you've described?

 

What happens when one of the apps goes down? I envision the InterProcessLock
as a locking model used between two low/medium chatty apps that want to
write to the same file that may or may not be running at the same time.

RE: Name for MutexLock?

[Dominik Psenner]

>The RemotingAppender tries to flush all message in shutdown but if
>things go really bad you may be losing some messages, this is true.

There can't be any guarantee anyway that all log messages are written before
the application goes down. There are circumstances where the operating
system takes over and terminates the application.

A popular phenomenon is an application that segmentation faults or when the
framework cannot find a shared library when it wants to load it.

In these cases the operating system takes over and terminates the
application and all loaded assemblies/resources with it without even
considering to shutdown the application gracefully. It may well the case
that the logging facility is fast enough to persist some events, but I would
not rely on it. The best things a developer may do is:

1) Application.Current.DispatcherUnhandledException += (object sender,
UnhandledExceptionEventArgs e) => { MessageBox.Show("ouch"); }
2) AppDomain.CurrentDomain.UnhandledException += (object sender,
DispatcherUnhandledExceptionEventArgs e) { MessageBox.Show("ouch"); }

And hope that the user needs some time to click "ok". :-)

RE: New RollingFileAppender semantics

[Dominik Psenner]

>Given that it appears that I am going to break the internal contract for
>RFA and the ambiguity in the current implementation it appears that we
>should create a new RFA.  (Perhaps called RollingFileAppender2??) with a
>clear definition of its semantics.

I expected this and favourite the rewrite of RFA.

>As such I would like to propose
>1) - Make CountDirection default to positive

Should it be modifiable? I'm unsure.

>2) - Make PreserveLogFileNameExtension default to true

+1, something else does not make sense in 99% of all cases.

>3) - Any date portion in a file name be prefixed with a . as if it were
>an extension.

+1, but one should be able to change the "spacer" character. "." is a
nuisance to regex parse a logfile, where "-" is tangentially easier.

>3) - Decide if PreserveLogFileNameExtension applies to both the
>datePattern and the size roll index or just to the size roll index.  I
>propose that it applies to size roll index and a new parameter
>(PreserveLogFileBase - defaults to true) be used to apply to the date
>roll.

*hmm* Could we make up an easier configuration as we're touching it already?
Just like in 4), I would love to see all rolling configuration stuff in a
section named  that lives near . I.e.
something like this:








>4) - Remove the ability to do the sample above.  In other words, only
>allow date editing within the datePattern.  The following config would
>achieve almost same file names.
>
>
>
>Generated file name would look like LogTest.201109181715.log
>If roll type become composite, then the files would look like
>LogTest.201109181715.1.log, LogTest.201109181715.2.log

3) covers this. +1

>5) - I propose that in the case of a maximum fixed size of roll backups,
>that the roll index become a fixed width field with leading zeros.
>Doing so will greatly simplify the deleting during rolling and make the
>process more robust because the pattern will be specific.  Currently the
>code sort of guesses by employing too many string.StartsWith() calls.
>Example, if MaxSizeRollBackups is set to 10, then the file names above
>would be
>LogTest.201109181715.01.log, LogTest.201109181715.02.log

Extending 4) we could become a:




 




>6) - Include a new MaxDateRollBackups parameter to limit the number of
>date periods that will be maintained.  Doing so is (I believe) currently
>unfeasible, if not impossible, given the ability to include a file name
>in the base pattern and not have a file name in the File parameter.

+1

Extending 4) this could become a:








>7) - Personally I would feel no loss if StaticFileName went away and was
>always treated as false, but I expect that many people would want to
>keep it.

What does it anyway? Enlighten me, please! :-)

Regards,
D.

Re: New RollingFileAppender semantics

[Dominik Psenner]

>> 
>> 
>> 
>> 
>> 
>> 
>
> Grouping the properties that affect the rolling strategy and separating
> them from the others makes sense to me.

It may be even a nice to implement it like that. This opens ways to
something like this:


  


  


But I don't know if that really fits into the "log4net is a clone of
log4j" philosophy. :-)
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

RE: New RollingFileAppender semantics

[Dominik Psenner]

>>> Grouping the properties that affect the rolling strategy and separating
>>> them from the others makes sense to me.
>
>> It may be even a nice to implement it like that. This opens ways to
>> something like this:
>
>> 
>>   
>> 
>> 
>>   
>> 
>
>You realize you are going down the road of boolean combinators here,
>aren't you?  Do we roll the file if one of the conditions is met, or all
>of them?

Depends on the conjunction used (And vs Or). In my example, the roll file
should be done daily and only if the file is not bigger than 5MB. I.e. the
algorithms are easy:

# and conjuntion
foreach condition in conditions:
  if not condition.isMet(file):
 return false
return true

# or conjuction
foreach condition in conditions:
  if condition.isMet(file):
 return true
return false

>> But I don't know if that really fits into the "log4net is a clone of
>> log4j" philosophy. :-)
>
>No problem here as we are not touching the architecture only one of the
>appenders - and a lot of variance is allowed here.  I realize you
>haven't been serious.

Not too serious, but most ideas start off being hilarious. *laughing*
Anyway, for now it's just an idea. Please discuss. :-)

RE: New RollingFileAppender semantics

[Dominik Psenner]

Sorry, I have a typo there with a misplaced "not".. This:

>In my example, the roll file should be done daily and only if the file is 
>not bigger than 5MB.

should be read as:

In my example, the roll file should be done daily and only if the file is
bigger than 5MB.

Sorry

RE: New RollingFileAppender semantics

[Dominik Psenner]

>What you are suggesting is completely different from the current
>semantics.
>Until this email, I understood your example to be equivalent to a
>composite roll in the current implementation.  In a composite roll, two
>different types of rolling take place.  One on the date/time boundary
>and one on the size boundary.  Resulting in
>File.datetime1.1
>File.datetime1.2
>File.datetime2.1
>File.datetime2.2
>
>I think that preserving this type of roll is important.  Currently we
>have Date, Size and Composite rolling.  If I have understood what you
>are suggesting, you are suggesting the addition of a 4th roll type
>called "ConditionRollingXX" that would have the semantic of AND or OR of
>the two (hopefully only two) conditions.  XX would be the AND or OR for
>the type of condition.  If there are more than two conditions, what are
>they?

Maybe something like "Date", "Size", "ApplicationUptime", "RPCTrigger", .. ?

>Did I understand correctly and is this needed?

I believe that I have to explain this further. My idea is to split the
rolling into two parts:

 * rolling condition
 * file naming strategy

This should ideally deprecate the different rolling strategies and their
hideous behaviour by replacing it with a clear API and a configuration
semantic. This here:


  
  


or this here (which is semantically the same, and would be just another
implementation of the "condition" interface):


  
  


Is much clearer than the old-fashioned thing:

RE: New RollingFileAppender semantics

[Dominik Psenner]

>>Maybe something like "Date", "Size", "ApplicationUptime", "RPCTrigger",
>.. ?
>RPCTrigger??

Yea. I just came up with this idea. If you for example have a remoting
appender that finally writes with a rolling file appender, other
applications could trigger a file roll with an RPC call. The specific
implementation could set a Boolean flag that causes the condition to match
on the next iteration and subsequently roll the file. But this is just a
fancy idea of how versatile this API could become. :-)

>What you are really saying is that the new code needs to have enough
>extension points that others could easily add new roll conditions.  My
>concern is in how to provide that functionality and get renaming and
>deleting right.

Since it's still our responsibility to rename files and the API just
provides only a "condition" and a "new file name" (or maybe even a set of
new filenames?) the code that renames (i.e. rolls) the file is still in the
base implementation.

>+1 or even +2 on the time stamp condition.
>I like the time stamp condition idea, but does that mean at hour 24 or
>24 hours from starting time?  I think it means hour 24, so what symbol
>could we add to make it relative to starting time.  Maybe a + so that
>"+24" means 24 hours from when I started.  Would a relative to start
>time take away your requirement for a ApplicationUptime roll condition?

So many pluses, I'm overwhelmed of the positive feedback! :-) I would stick
with the crond semantics here. They support these 5 cases:

1) * matches every number
2) 5 matches exactly 5
3) */5 matches everything with *%5 == 0, i.e. 0,5,10,15,20,25,..
4) 5,7 matches for 5 or 7
5) 5-7 matches 5,6 or 7

See here: http://adminschoice.com/crontab-quick-reference

This is simple and even more powerful than the old syntax. The configuration
would require some more syntactic sugar to identify the rolling strategies.
I.e. something like:


  
  


Or maybe:


  
  


Yet we would have to design a format that works for 3rd party
implementations too.

>Questions about rollFileNamingStrategy.
>Date makes sense, I assume that we would include the datePattern
>somewhere as   etc.
>How do we incorporate that with a size rollover to achieve names similar
>to what are produced now (or should be produced now) as
>File.datetime1.1
>File.datetime1.2
>File.datetime2.1
>File.datetime2.2
>
>It seems to me that we would need to pair a naming strategy with each
>roll strategy and indicate where that part of the name goes into the
>final file name.
>
>This brings me to File= parameter that has {Date} and {Size} etc. to
>indicate where date and size patterns are to be inserted.  (Likewise for
>any other rolling condition.) If this idea is acceptable, then we do not
>have to worry about the date pattern separator or preserve extension
>etc. because it is all handled by the file pattern.  The biggest
>downside that I see at this time is scanning the File= parameter to
>determine what goes where to create the directory search, but it should
>be doable without too much unfixable code.
>

This will become tricky. Rolling by date and a unpredictable part in the
filename (like date) forces a algorithm candidate to search a set of files
and therefore the algorithm automatically degrades to something in between
O(n) and O(n^3). Rotating often a large amount of backups can devastate the
performance. So maybe we'll have to distinguish two rolling strategies and
never mix them:

1) either by date, which is simply a copy of the file and the existing file
becomes truncated
2) or by incremental number, which allows an upper bound of files, but still
does copy the current file and truncates it afterwards

>>Is much clearer than the old-fashioned thing:
>Agreed

Hooray!

Re: New RollingFileAppender semantics

[Dominik Psenner]

On 09/20/2011 05:06 PM, Roy Chastain wrote:
> I have already written code that could parse the old datepattern and
> determine where ? needed to go to do the file directory search.  That
> code or a close relative can survive into the new model so, the
> directory search is still just a single pass with a mask.  I even fixed
> that mask to take into account the size roll increment number also,
> which is why I wanted to make fixed width.
> 
> I really think we need to provide for multiple name parts as proposed
> above.  I think I should be able to keep the performance acceptable.

Should I try to write down the API? It should be doable in a couple of
hours and right now it looks like I have some free time tomorrow around
20°°-22°°. If so, is there somewhere a sandbox that I could use?
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Re: Dropping Support for .NET CF 1.0 and SSCLI 1.0 in log4net 1.2.11

[Dominik Psenner]

On 09/20/2011 06:41 PM, Stefan Bodewig wrote:
> So before I try to find Visual Studio 2003 - and accept that you can't
> build a log4net release without an IDE you have to pay for - I thought I
> might simply ask if anybody was opposed to have log4net 1.2.11 simply
> strike the two platforms.

+1

But we should probably remark in the README and at the download page
that we could put some effort into providing the binaries if someone
really needs them.
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

RE: New RollingFileAppender semantics

[Dominik Psenner]

>-Original Message-
>From: Roy Chastain [mailto:r...@roychastain.org]
>Sent: Wednesday, September 21, 2011 12:14 AM
>To: Log4NET Dev
>Subject: RE: New RollingFileAppender semantics
>
>>Should I try to write down the API? It should be doable in a couple of
>hours and
>>right now it looks like I have some free time tomorrow around 20°°-22°°.
>If so,
>>is there somewhere a sandbox that I could use?
>I am not sure what you are asking about a sand box etc, but anything that
>you wish to do to further explain your ideas, is welcome.

A sandbox is typically a branch or repository that is used to "play" around
with new code. I'll probably have to share that code through bitbucket as I
don't have the privileges to commit to the repository. Or can I get
sufficient privileges to commit to a branch in the ASF repository?

Roy, didn't you say you already did some work there? Would you share it so
that we don't duplicate effort?

RE: New RollingFileAppender semantics

[Dominik Psenner]

>My current plan is to dummy up a new RFA (configuration points) and
>write the XML doc for the configuration points and pass the result of
>that out for review and comments.  We must be explicit about the
>semantics of the new configuration.  We have already observed cases
>where I have not correctly interrupted the meaning of Dominik was
>suggesting. Once we agree on the configuration and semantics of that
>configuration, things can go better.
>
>I am also thinking about not deriving from FileAppender as Curt
>mentioned in the emails about the new RFA for log4j.  I will have to
>think about that more after we finalize the new design and I see the new
>FileAppender with the Mutex locking etc.
>
>If we want to support Mutex locking in RFA(NG), then it might be best to
>continue to derive from FileAppender and wrap all the rolling in the
>Mutex.  If we do not want to support that type of locking, then not
>getting involved with FileAppender may make the code cleaner, but it
>will increase the amount of code.

Thanks for the information. This means that today, specifically in the
evening around 20°°, I'm going to try my best to come up with a
"RollingFileAppenderNG" implementation that derives from FileAppender.
Therefore the first layout of the RFA-NG will be much like the current RFA.
We can still iterate over write&review cycles as often as it takes.

Re: New RollingFileAppender semantics

[Dominik Psenner]

> Thanks for the information. This means that today, specifically in the
> evening around 20°°, I'm going to try my best to come up with a
> "RollingFileAppenderNG" implementation that derives from FileAppender.
> Therefore the first layout of the RFA-NG will be much like the current RFA.
> We can still iterate over write&review cycles as often as it takes.

Here it comes:

https://bitbucket.org/NachbarsLumpi/log4net-patches/src/197c2b931afe/RFA-NG

It's not finished at all, but it should make it obvious where this
road leads us to. This patch applies safely to trunk@1173276.
Feedbacks are welcome!
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

Re: New RollingFileAppender semantics

[Dominik Psenner]

Sorry for the noise, but I have to correct myself. This here is the right link:

https://bitbucket.org/NachbarsLumpi/log4net-patches/src/tip/RFA-NG

The concentration is almost gone, I better go off to bed now. :-)
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

RE: New RollingFileAppender semantics

[Dominik Psenner]

>Take a look at org.apache.log4j.rolling.RollingFileAppender which has
>pluggable rolling and file naming strategies.
>
>http://logging.apache.org/log4j/1.2/apidocs/index.html
>
>For a little ancient history, log4j 1.2 has two classes named
>RollingFileAppender, the original in org.apache.log4j and a next generation
>(aka 2005 or so) implementation from the abandoned log4j 1.3 effort in
>org.apache.log4j.rolling. The o.a.l.r.RFA still has its problems, but is an
>improvement over o.a.l.RFA.

I've so far found this:

http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/r
olling/package-tree.html

Despite the fact that it is there in "extras", you're suggesting that it was
abandoned? Why?

RE: I will not be working on RFA Next Gen

[Dominik Psenner]

>Best of luck to all.

Sad news, I wish you the best!

RE: unsubscribe

[Dominik Psenner]

log4net-dev-unsubscr...@logging.apache.org

 

  _  

From: Frank Watkins [mailto:fwatk...@rals.com] 
Sent: Wednesday, September 28, 2011 4:10 PM
To: Log4NET Dev
Subject: RE: unsubscribe

 

 

 

Thanks,

 

Frank 

 

Product Verification Test

Medical Automation Systems

E-mail:   fwatk...@rals.com

Business Phone #: 434-951-2926

Internal Phone: x3043

 

  _  

From: Walden H. Leverich [mailto:wald...@techsoftinc.com] 
Sent: Wednesday, September 28, 2011 10:08 AM
To: log4net-dev@logging.apache.org
Subject: unsubscribe

 

unsubscribe

 


-- 
Walden H Leverich III
Tech Software & 

BEC - IRBManager
(516) 627-3800 x3051
wald...@techsoftinc.com
http://www.TechSoftInc.com  
http://www.IRBManager.com  


Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)

 

RE: TPL DataFlows

[Dominik Psenner]

Hey Ron,

 

I actually implemented something similar in a product we're distributing.
There I used plain delegates (lambda expressions) in favour of not having a
dependency to the TPL library, but that's not the big deal anyway. It works
astonishingly well, but I had to add a small safety condition:

 

Since the creation of asynchronous logging events is extremely fast and
blocks the application almost for no-time, any application could possibly
overflow the logging facility with so much events that it can't handle them
anymore. The result is that the queues grow and grow until the application
goes out of memory.

 

The solution I made is simple, but effective. Before the logging event is
processed asynchronously, I check the queue size and decide there if I
should block the calling application for a small portion of time per logging
event. I.e. something similar to this:

 

public void QueueUserWorkItem(T item)

{

   bool blockInvoker = false;

   int blockTime = 0;

 

   lock (itemsLock)

   {

   // queue the item

   items.Enqueue(item);

 

   if (items.Count > 1000)

   {

   blockInvoker =
true;

   if (items.Count >
100)

 
blockTime = 10;

   else if
(items.Count > 50)

 
blockTime = 5;

   else if
(items.Count > 25)

 
blockTime = 3;

   else if
(items.Count > 10)

 
blockTime = 2;

   else if
(items.Count > 5)

 
blockTime = 1; // actually block the application

   else if
(items.Count > 1)

 
blockTime = 0; // give another thread the chance to get the cpu

   }

   }

 

   // out of any lock (such that we dont
lock ourselves) block the invoker

   if (blockInvoker)

   {

   Thread.Sleep(blockTime);

   }

}

 

This gradually slows the calling application and works pretty fine if one
does stupid things like:

 

while (true) {

  logger.Info("yehaw");

}

 

JMTC,

Dominik

 

  _  

From: Ron Grabowski [mailto:rongrabow...@yahoo.com] 
Sent: Thursday, September 29, 2011 5:59 AM
To: log4net-dev
Subject: TPL DataFlows

 

Has anyone played around with TPL DataFlows yet? It looks like it could be
next step beyond using a concurrent queue for async message processing. Once
a log event has had the appropriate thread specific properties evaluated it
could be posted to a BroadcastBlock which would asynchronously post the
message to appenders:

 

http://weblogs.asp.net/mjarguello/archive/2011/03/15/asynchrony-in-c-5-dataf
low-async-logger-sample.aspx

 

 

 

 

RFA-NG review

[Dominik Psenner]

Hi guys.

I request some feedback on the RFA-NG patch while I'm working on it.

For now the most recent version of the patch is still at
https://bitbucket.org/NachbarsLumpi/log4net-patches/src/tip/RFA-NG and it
should apply safely to the log4net trunk.

Please let me know if I am able to help you with reviewing the code.

Greetings,
Dominik

Re: RFA-NG review

[Dominik Psenner]

Hi Stefan,

> The coming weekend - including the German holiday on Monday - is going
> to be quite hectic (two birthdays in the family and a "Polterabend"[1]
> in the neighborhood) for me.  I don't expect to find time looking over
> your code until next week.  But I promise I'll do.


Don't forget the "böllern"
(http://www.verlobung-hochzeit.de/hochzeits-brauch-tradition/brauch25-wecken-der-brautleute.php).
In the end I'm kind of german, too. :-) Get the party on and see to it
once you've got some free hours.


Reviewing it all could become quite difficult since this is a huge
patch. The most effective review method I know is mailing the patch and
comment parts of it inline. For example:


+   #region Protected Inner Classes
+

Don't forget the xml description

+   protected enum MatchType
+   {
+   Nothing,
+   Exact,
+   Remainder,
+   }
+
+   #endregion


Do you wanna try that? Do you know something better suited that maybe is
part of JIRA? :-)
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

RE: RFA-NG review

[Dominik Psenner]

>> Don't forget the "böllern"
>
>Fortunately we don't do that in the lower rhine area 8-)

How comes that? The last time I've seen it was about a month ago. There they
used flasks of gas having the length of half a meter. It could have easily
been mistaken for an airstrike. *laughing* But, to tell you the truth, I
only love it as far as I'm not a witness of the terrible noise. :-D

>> Reviewing it all could become quite difficult since this is a huge
>> patch. The most effective review method I know is mailing the patch and
>> comment parts of it inline.
>
>We have a ReviewBoard instance running at https://reviews.apache.org/
>and I've just asked to have a group added for log4net.
>
>I've never used ReviewBoard before but the described pre-commit workflow
>sounds as if it was exactly what you described with the email based
>workflow.

Sounds great! I try to dig up some spare time. Please let me know once the
organizational part is settled.

Regards,
D.

RE: WebSite for 1.2.11 - Please Review

[Dominik Psenner]

I believe the prerequisites in FAQ could be updated to not mention .net
runtime 1.0/1.1 since the release doesn't include binaries for them.

RE: WebSite for 1.2.11 - Please Review

[Dominik Psenner]

I'm going back into my hideout .. sorry for the noise.

>-Original Message-
>From: Stefan Bodewig [mailto:bode...@apache.org]
>Sent: Wednesday, October 05, 2011 1:47 PM
>To: log4net-dev@logging.apache.org
>Subject: Re: WebSite for 1.2.11 - Please Review
>
>On 2011-10-05, Dominik Psenner wrote:
>
>> I believe the prerequisites in FAQ could be updated to not mention .net
>> runtime 1.0/1.1 since the release doesn't include binaries for them.
>
>It does (it won't contain binaries for Compact Framework 1.0).
>
>Stefan

RE: WebSite for 1.2.11 - Please Review

[Dominik Psenner]

>At least it has now been proof-read by two Germans and at least one
>other non-native-speaker - Dominik said he was kind-of-German.

:-) I believe that it's time to clear up some things. I was born in Italy
and live there until here and now. Nevertheless, my mother tongue is German.
Due to the fact that I'm a citizen of Italy I speak Italian too and as last
but not least I got used to speak English as for my profession.

The only thing I found in the FAQ was a fault of mine, which means I
probably did not read it careful enough to find any objections. :-) The FAQ
is probably going to be fine.

Regards,
D.

RE: ReviewBoard for log4net

[Dominik Psenner]

>for anybody who wants to give it a try, there now is a ReviewBoard group
>at 

Nice! Unfortunately I won't be able to try this before Monday.

RE: [VOTE] Release Apache log4net 1.2.11 based on RC1

[Dominik Psenner]

+1

RE: [jira] [Commented] (LOG4NET-318) log4net doesn't pass verification

[Dominik Psenner]

FWIW, googling gave me this:

http://www.mail-archive.com/mono-cecil@googlegroups.com/msg02926.html

>-Original Message-
>From: NN (Commented) (JIRA) [mailto:j...@apache.org]
>Sent: Thursday, December 01, 2011 10:15 PM
>To: log4net-dev@logging.apache.org
>Subject: [jira] [Commented] (LOG4NET-318) log4net doesn't pass verification
>
>
>[ https://issues.apache.org/jira/browse/LOG4NET-
>318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
>tabpanel&focusedCommentId=13161174#comment-13161174 ]
>
>NN commented on LOG4NET-318:
>
>
>Unfortunately me too.
>
>I have asked question in stackoverflow:
>http://stackoverflow.com/questions/8297419/log4net-verification
>But no answers.
>
>It would be great if you find the cause.
>Maybe bug in PEVerify ?
>
>Thanks.
>
>> log4net doesn't pass verification
>> -
>>
>> Key: LOG4NET-318
>> URL: https://issues.apache.org/jira/browse/LOG4NET-318
>> Project: Log4net
>>  Issue Type: Improvement
>> Environment: Windows
>>Reporter: NN
>>  Labels: peverify
>>
>> Run PEVerify tool. (http://msdn.microsoft.com/en-
>us/library/62bwd2yd(v=VS.100).aspx)
>> I get
>> [IL]: Error: [log4net.dll :
>log4net.Plugin.RemoteLoggingServerPlugin::Attach][offset 0x0029] Method
>is not visible.
>> It is a good idea to add verification step for the build process.
>> Thanks.
>
>--
>This message is automatically generated by JIRA.
>If you think it was sent incorrectly, please contact your JIRA
>administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>

RE: RollingFileAppender overwrites file if already rolled by another process

[Dominik Psenner]

Hi Walden,

>The problem I'm seeing is that if another process has already rolled the 
>file (assuming a locking model other than exclusive) then the second (and 
>subsequent) process to perform the same "roll" will attempt to open the new

>file with a false for the append parm and thus overwrite anything in the 
>file already.

That's a decision that was made at design time. :-) Without taking a closer
look at it, I would guess that 's/false/true/' wouldn't work either. It
would at best truncate the file, too. At worst it would raise typical race
conditions (random behaviour) because context switches can happen at every
non-atomic operation of all processes involved. The only real solutions are
to either:

1] use exclusive lock when logging into the same file from several processes
2] configure an event/rcp appender that invokes a file appender which is the
only one appending to the file

JMTC and comments welcome.

Cheers,
Dominik

Re: Who owns the log4net nuget package?

[Dominik Psenner]

On 01/14/2012 10:41 PM, Ron Grabowski wrote:
> Does anyone know who owns the log4net nuget package?
> 
> http://nuget.org/packages/log4net
> http://blog.cincura.net/232619-log4net-back-alive-on-nuget/
> 
> We're the 6th most populate package on nuget! Can someone explain what
> it would take to get the nuget package files into our svn repository?

A lot of guessing, but entering the username "cincura.net" as a webpage
leads to http://www.x2develop.com/ and their contact website
http://www.x2develop.com/contact.html shows a contact to "Mgr. Jiří
Činčura". Contacting him could be a good try?

Cheers
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

Async logging

[Dominik Psenner]

Hi,

 

In response to
https://issues.apache.org/jira/browse/LOG4NET-344?focusedCommentId=13291557

&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comme
nt-13291557 I would like to start a discussion how log4net should support
asynchronous logging. Tom Tang implemented a general async forwarding
appender that glues together other appenders and thus adds general async
processing of log events. He implemented a good idea that misses only a few
small things to be an awesome improvement.

 

My objections are:

 

* the queue size should be configurable

* the ThreadPool should be used in favour over a designated worker
Thread

* if the queue is full, it should fallback to synchronous logging,
shouldn't it?

* queued log events should be processed when the appender gets
disposed

 

Cheers,

Dominik

RE: Async logging

[Dominik Psenner]

Hi Christian,

thanks for the feedback.

>> · the ThreadPool should be used in favour over a designated
>worker
>> Thread
>
>no idea becuase I have no clue on .NET, but it sounds like fun :-)

It just means that it is not written as:

new Thread(() => { ..; Thread.Sleep(x); }

but rather there is only a worker thread active when there are pending log
events. The algorithm is quite simple:

Append(logEvent) {
 Queue.append(logEvent)
 If(queue.size == 1) {
  Threadpool.Invoke(ForwardMessages)
 }
}

ForwardMessages() {
 While(Queue.count > 0){
  # forward
 }
}

Of course it needs some locking and other dark magic in between to work as
expected.

>> · if the queue is full, it should fallback to synchronous
>logging,
>> shouldn’t it?
>
>Not sure on this: this would probably impact the application in terms
>of performance right?

Yes. But it does in a "safer" manner. The philosophy is much like safer sex.
Either strategy means:

case Strategy.IGNORE:
 RAM caching => OutOfMemoryException
case Strategy.DISMISS:
 loss of events, I'm not a great fan of this
case Strategy.SYNC:
 the calling application is slowed down approximately to how fast the log
events can be serialized to the underlying I/O, which means the async
implementation behaves more like a buffer

>Probably this should be configurable to:
>
>QUEUE_OVERFLOW_STRATEGY=DISMISS -> throws away the log events
>QUEUE_OVERFLOW_STRATEGY=SYNC -> goes back to synchronized logging

Good point. And for brave developers:
QUEUE_OVERFLOW_STRATEGY=IGNORE -> ignores queue overflow

>In either case, a warning message should be generated.

Of course. But we should make sure to not stress the CPU with too many
additional warnings since it probably would be already at its limits.

>Another interesting feature would  to set a threshhold for the queue.
>Lets assume it is 100, and 100 messages are in the queue while 150 are
>allowed, one could get a warning log that the threshhold of 100 is
>passed.

Is it really required to make that configurable? If so, I would make it an
optional configuration with the fallback to something like
THRESHOLD=MAX_QUEUE_SIZE*0.9 that outputs warnings whenever the queue size
hits a multiple of TRESHOLD (i.e. queue.size % TRESHOLD == 0).

>
>> · queued log events should be processed when the appender gets
>> disposed
>
>+1

The problem here is that the CLR may take over (i.e. on crashes) and simply
terminate the appender together with the assembly that loaded it. Does
somebody know a way to preserve the last few log messages from destruction
in those corner cases?

RE: Welcome Dominik Psenner as new Committer

[Dominik Psenner]

>Dear log4net community,
>
>it is my pleasure to inform you, Dominik has been elected as a new
>committer to the project.  He's been active around here for quite some
>time and will now be able to work on the code base directly.  I'm sure
>the project is going to benefit a lot from him.
>
>Welcome Dominik

Hi community,

thanks Stefan for the warm welcome! I'm glad to have been chosen and am sure
that our joint efforts will bear great benefits to the project.

Cheers,
Dominik

Re: recommendation for AspNetPatternLayoutConverter

[Dominik Psenner]

On 07/27/2012 10:42 PM, George Chung wrote:
> It currently defines this abstract method:
> 
> protected abstract
> void Convert(TextWriter writer, LoggingEvent loggingEvent, HttpContext 
> httpContext)
> 
> I would recommend changing it to:
> 
> protected abstract void Convert(TextWriter writer, LoggingEvent loggingEvent, 
> HttpContext*Base* httpContext)
> 
> Effectively, HttpContext.Current is not very useful anymore in more
> recent versions of ASP.NET <http://ASP.NET>. As they are promoting an
> asynchronous programming model where operations complete on completion
> threads. And they also encourage the use of the ParallelTaskLibrary for
> queuing work items. The bulk of your operations are going to execute on
> these threads, and on these threads, HttpContext.Current is null.
> 
> HttpContextBase is what's being used now and it's easy to convert
> HttpContext.Current to an HttpContextBase like this:
> 
> new HttpContextWrapper(HttpContext.Current)
> 
> Here's some more info on the matter.
> 
> http://www.splinter.com.au/httpcontext-vs-httpcontextbase-vs-httpcontext/

I did not change the signature and test the impact on compatibility to
previous versions of log4net, but I would assume that since HttpContext
is not an implementation of HttpContextBase it will not work out of the
box, would it?

And on top of that, HttpContextBase exists only for .NET 3.5/4.0, which
breaks log4net for .NET 1.0/2.0/3.0 unless we juggle around with build
conditionals.

Maybe a "reimplemtation" of the AspNetPatternLayoutConverter would suit
the new usecase better?
-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##



signature.asc
Description: OpenPGP digital signature

RE: recommendation for AspNetPatternLayoutConverter

[Dominik Psenner]

No need to worry George. :-) Personally I prefer to stay on the bleeding
edge of development. Though, this issue is currently not a problem to me.
Would you try and get something done that is backwards compatible? I will
commit any useful patches.

 

Cheers

 

  _  

From: George Chung [mailto:geo...@glympse.com] 
Sent: Monday, July 30, 2012 4:40 AM
To: Log4NET Dev
Subject: Re: recommendation for AspNetPatternLayoutConverter

 

Yes, I completely discounted backwards compatibility, sorry.

On Sun, Jul 29, 2012 at 2:13 PM, Dominik Psenner  wrote:

On 07/27/2012 10:42 PM, George Chung wrote:
> It currently defines this abstract method:
>
> protected abstract
> void Convert(TextWriter writer, LoggingEvent loggingEvent, HttpContext
httpContext)
>
> I would recommend changing it to:
>

> protected abstract void Convert(TextWriter writer, LoggingEvent
loggingEvent, HttpContext*Base* httpContext)

>
> Effectively, HttpContext.Current is not very useful anymore in more

> recent versions of ASP.NET <http://ASP.NET>. As they are promoting an

> asynchronous programming model where operations complete on completion
> threads. And they also encourage the use of the ParallelTaskLibrary for
> queuing work items. The bulk of your operations are going to execute on
> these threads, and on these threads, HttpContext.Current is null.
>
> HttpContextBase is what's being used now and it's easy to convert
> HttpContext.Current to an HttpContextBase like this:
>
> new HttpContextWrapper(HttpContext.Current)
>
> Here's some more info on the matter.
>
> http://www.splinter.com.au/httpcontext-vs-httpcontextbase-vs-httpcontext/

I did not change the signature and test the impact on compatibility to
previous versions of log4net, but I would assume that since HttpContext
is not an implementation of HttpContextBase it will not work out of the
box, would it?

And on top of that, HttpContextBase exists only for .NET 3.5/4.0, which
breaks log4net for .NET 1.0/2.0/3.0 unless we juggle around with build
conditionals.

Maybe a "reimplemtation" of the AspNetPatternLayoutConverter would suit
the new usecase better?
--
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

 

RE: recommendation for AspNetPatternLayoutConverter

[Dominik Psenner]

I created LOG4NET-350 [1] which reflects this issue.

 

[1]  <https://issues.apache.org/jira/browse/LOG4NET-350>
https://issues.apache.org/jira/browse/LOG4NET-350

 

  _  

From: Dominik Psenner [mailto:dpsen...@gmail.com] 
Sent: Monday, July 30, 2012 8:08 AM
To: 'Log4NET Dev'
Subject: RE: recommendation for AspNetPatternLayoutConverter

 

No need to worry George. :-) Personally I prefer to stay on the bleeding
edge of development. Though, this issue is currently not a problem to me.
Would you try and get something done that is backwards compatible? I will
commit any useful patches.

 

Cheers

 

  _  

From: George Chung [mailto:geo...@glympse.com] 
Sent: Monday, July 30, 2012 4:40 AM
To: Log4NET Dev
Subject: Re: recommendation for AspNetPatternLayoutConverter

 

Yes, I completely discounted backwards compatibility, sorry.

On Sun, Jul 29, 2012 at 2:13 PM, Dominik Psenner  wrote:

On 07/27/2012 10:42 PM, George Chung wrote:
> It currently defines this abstract method:
>
> protected abstract
> void Convert(TextWriter writer, LoggingEvent loggingEvent, HttpContext
httpContext)
>
> I would recommend changing it to:
>

> protected abstract void Convert(TextWriter writer, LoggingEvent
loggingEvent, HttpContext*Base* httpContext)

>
> Effectively, HttpContext.Current is not very useful anymore in more

> recent versions of ASP.NET <http://ASP.NET>. As they are promoting an

> asynchronous programming model where operations complete on completion
> threads. And they also encourage the use of the ParallelTaskLibrary for
> queuing work items. The bulk of your operations are going to execute on
> these threads, and on these threads, HttpContext.Current is null.
>
> HttpContextBase is what's being used now and it's easy to convert
> HttpContext.Current to an HttpContextBase like this:
>
> new HttpContextWrapper(HttpContext.Current)
>
> Here's some more info on the matter.
>
> http://www.splinter.com.au/httpcontext-vs-httpcontextbase-vs-httpcontext/

I did not change the signature and test the impact on compatibility to
previous versions of log4net, but I would assume that since HttpContext
is not an implementation of HttpContextBase it will not work out of the
box, would it?

And on top of that, HttpContextBase exists only for .NET 3.5/4.0, which
breaks log4net for .NET 1.0/2.0/3.0 unless we juggle around with build
conditionals.

Maybe a "reimplemtation" of the AspNetPatternLayoutConverter would suit
the new usecase better?
--
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

 

Re: database and string

[Dominik Psenner]

Try DbType Text.

2012/9/20 jacklitt :
>
> Hi
>
> I am using log4net to loga to database
>
> one of the columns is set as
>
> 
> 
> 
> 
> 
> 
>
> however, i want to be able to save >4000 chatracters
> Currenty I have xml objects that I deserialise to string and then this is
> saved - however, itt is truncated to 4000.
>
> Is there a string type that allows maxsize to be set.
>
> Thanks
> --
> View this message in context: 
> http://old.nabble.com/database-and-string-tp34458039p34458039.html
> Sent from the Log4net - Dev mailing list archive at Nabble.com.
>



-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

RE: log4net RollingLogFileAppender: is this possible to set limit for TOTAL size of all log files?

[Dominik Psenner]

>If I set
>maximumFileSize=10MB and maxSizeRollBackups=10, I will get 10 files for a
>  with total size 100MB. During the next day () I will get
>another  10 files for the   with total size 100MB; the previous 10
>files (ones for the ) will NOT be removed when new files (for the
>) start appearing.
>
>I really tested the Appender in such situation.
>
>So, the limit affects EACH SINGLE DAY; but not the whole bunch of .log
>files
>in teh given folder

Now I got your point. However, keeping files of past days once the rolling
runs by date is a feature documented also at [2]. There it says:

-- quote --
This example show how to configure the RollingFileAppender to roll log files
on a date period and within a date period on file size. For each day only
the last 10 files of 1MB will be kept.
-- eof quote --

Since you only want to limit the file count anyway, it makes sense to not
roll by date but by file size, doesn't it? Doing so gives you the wanted
behaviour, but filenames won't contain the date. Sorry for the
inconvenience.

Clearly the above is only a workaround and a date in the filename would be
nice, but it is not trivial to implement such a rolling without being
computationally expensive.

The problem lies in identifying the files that should be deleted even if
those files are many thousands or their filename contains a date that is
years in the past. One can either probe a filename or probe if there is a
file for a specific date. Both strategies do not fit into the current
implementation of the rolling file appender. There are several known
problems with the rolling file appender and a rewrite is in discussion. To
document this discussion I've CC'ed the dev mailing list.

If you believe that you need this as a feature, please leave a feature
request in JIRA at [1]. Of course it is no guarantee that one of the
developers will work on this issue any time soon, and therefore I encourage
you to actively work on it if you need it soon. Patches that improve log4net
are always welcome!

Best regards,
Dominik

[1] https://issues.apache.org/jira/browse/LOG4NET
[2] http://logging.apache.org/log4net/release/config-examples.html

RE: Log file are not written in IIS7

[Dominik Psenner]

Hi,

>Am using log4net in my application. It works fine when i run via code. But
>when i host it in IIS7 the log files are not written.
>
>What is the preferred account used to write to the log file directory, I
>tried network and network service and they did not work. I tried iusr and
>that worked . Which is the rght user account to work with logfiles?

you could try to add this to your web.config:





Cheers,
D.

RE: Object Reference issue in changing the Log file name dynamically in threads

[Dominik Psenner]

Hi,

>Am creating a web application using Vb.Net for data processing. I am
>implementing multi threading in processing functions. And also i used
>log4net to log the function calls and steps.

This is not going to work like this. The log4net-way is by defining
different appenders and filter the events there. Take this as a reference:

http://stackoverflow.com/questions/1612317/how-to-log-into-separate-files-pe
r-thread-with-log4net

Cheers,
D.

RE: Object Reference issue in changing the Log file name dynamically in threads

[Dominik Psenner]

>This Works fine

Glad to hear that.

>.. i am unable to use static appenders. Because i need to
>change the name of the log file based on my processing function in my
>application.

I can understand your problem. Unfortunately there is no easy way to change
the logfile dynamically at runtime. It all comes down to spawning and
disposal of file appenders at runtime.

>Now my problem is am unable to use httpcontext or session
>objects in threads.. Is there any way to do this?

Log4net does not imply rules on the scope of httpcontext or session
variables in threads. Thus this does not seem to be a log4net problem at
all. If I did not understand what you were saying here, please rephrase the
question.

>Or else how can i creating log files dynamically?

In my opinion there's no safe way to do that. But someone elses mileage may
vary. A logfile is equivalent to a single (rolling) file appender and a
single (rolling) file appender can only append log events into exactly one
logfile. If you somehow manage to change that logfile at runtime it will
affect all other log events that should be written by this (rolling) file
appender too. Whether or not they come from another thread doesn't matter.

Generally said, the "logic" of dispatching messages should be placed into
event filters that are assigned to an appender. You could create a hierarchy
of remoting appenders that finally sink log events into a rolling file
appender, but in my humble opinion this construct is far to complex for a
mere logger. The worst logger you can have is one that does not log at all
because it was designed too complicated.

Therefore I encourage you to log events into a database. Then you can fetch
log events from that database with all different fancy logic you need.

Cheers,
D.

RE: Log file are not written in IIS7

[Dominik Psenner]

>what is the use of this property.. If i set this what are all the
>permissions
>i need to set for the log folder in iis.

I assumed that you configured log4net to log to a file to which IIS has no
permissions to write to. Thus you have to give IIS either the permissions or
impersonate the web application into a user that has the permissions. How to
do that can probably be found in the IIS or Windows manual.

Re: [jira] [Commented] (LOG4NET-178) Log4Net stops logging after appdomain recycle of aps.net2.0 application

[Dominik Psenner]

Hi George,

would You please post this in JIRA so that others that watch the issue
get an update too? It may become helpful for whoever runs into similar
problems and could actually lead to resolve LOG4NET-178 once and for
all.

Cheers,
Dominik

2012/10/26 George Chung :
> OK, I don't do anything special that I do in my code except set the AppName.
>
> Here's what you'll want to do.
>
> Set this in your Web.Config
>
>   
> 
>
> If this setting is false, which is the default, log4net will silently
> swallow any exceptions before returning to your code. If it's set to true,
> then log4net still swallows the exceptions, but reports them. If you run
> your ASP.NET app in the debugger and you have configured a TraceAppender,
> you'll see log4net output in the Output window. While still in the debugger,
> touch your web.config, thus forcing the AppDomain to reload the app. Note,
> you'll still be in the debugger. Visit a page hosted by your ASP.NET app to
> cause your Application_Startup() to execute. Execute something that you know
> will trigger a log4net log event. At this point, if log4net is having
> problems, you'll see gobs of log4net output in the Output window.
>
> I used this technique to figure out why my ASP.NET app was not logging in
> release mode. Well, it's because I configured log4net to capture line
> numbers. Well, line numbers don't exist in release builds. By using the
> above technique, I was able to see that I was getting an exception trying to
> insert an empty string into an integer column in my configured
> AdoNetAppender.
>
> On Fri, Oct 26, 2012 at 12:34 PM, George Chung  wrote:
>>
>> I know I explicitly initialize some log4net setting in
>> Application_Startup. Let me look it up.
>>
>>
>> On Thu, Oct 25, 2012 at 11:45 PM, Dominik Psenner (JIRA) 
>> wrote:
>>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/LOG4NET-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484745#comment-13484745
>>> ]
>>>
>>> Dominik Psenner commented on LOG4NET-178:
>>> -
>>>
>>> I am no expert on IIS web applications, but it would look like a
>>> misconfigured log4net configuration and/or a missing initialization. If
>>> logging starts by changing the web.config, log4net is "watching" for changes
>>> in the web.config and respawns the appenders when that happens. This means
>>> that either:
>>>
>>> * log4net gets never started
>>> * log4net gets stopped and not restarted
>>>
>>> Thus - in theory - adding an initialization in the right spot alike the
>>> one in comment
>>> https://issues.apache.org/jira/browse/LOG4NET-178?focusedCommentId=13127649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13127649
>>> could fix the issue.
>>>
>>> > Log4Net stops logging after appdomain recycle of aps.net2.0 application
>>> > ---
>>> >
>>> > Key: LOG4NET-178
>>> > URL: https://issues.apache.org/jira/browse/LOG4NET-178
>>> > Project: Log4net
>>> >  Issue Type: Bug
>>> >  Components: Appenders
>>> >Affects Versions: 1.2.10
>>> > Environment: Windows server 2003
>>> >Reporter: Richard Nijkamp
>>> > Fix For: 1.2 Maintenance Release
>>> >
>>> >
>>> > Dear sir/madam,
>>> >  We are using Log4Net 1.2.10. We encounter the problem that Log4net
>>> > doesn't continue logging after an event that triggers an appdomain
>>> > recycle/restart.
>>> >  In the global.asax we start the logging with:
>>> >  private static readonly ILog log =
>>> > LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);
>>> > Logging works flawless when the application is started for the first
>>> > time. After sometime it might occur that the appdomain gets recycled due 
>>> > to
>>> > inactivity of the web application. We use the following code in
>>> > Application_end():
>>> > log.Info("*** Application end ***");
>>> > log4net.LogManager.Shutdown();
>>> > After this function the application gets restarted and the
>>> > Application_start() method executes and writes new lines to the log.

Add new FAQ entry

[Dominik Psenner]

Hi,

I gotta question about adding a new FAQ entry. I don't know how the build
system works behind the scenes but I believe it should be enough to update:

src\site\xdoc\release\faq.xml

and commit. The website should then update itself, doesn't it?

Cheers,
D.

FW: Add new FAQ entry

[Dominik Psenner]

Hi,

Yesterday I posted this message on log4net-dev but maybe noone noticed. :-)
Is there someone around that knows how the publishing of the log4net website
works?

Cheers,
D.

>-Original Message-
>From: Dominik Psenner [mailto:dpsen...@gmail.com]
>Sent: Tuesday, November 27, 2012 1:19 PM
>To: 'Log4NET Dev'
>Subject: Add new FAQ entry
>
>Hi,
>
>I gotta question about adding a new FAQ entry. I don't know how the build
>system works behind the scenes but I believe it should be enough to update:
>
>src\site\xdoc\release\faq.xml
>
>and commit. The website should then update itself, doesn't it?
>
>Cheers,
>D.

RE: FW: Add new FAQ entry

[Dominik Psenner]

Good morning Christian,

thanks for the fast feedback. That wiki was the one I've been searching for.
:-) I'll post back if I run into more trouble. Thanks!

Cheers,
D.

>-Original Message-
>From: Christian Grobmeier [mailto:grobme...@gmail.com]
>Sent: Wednesday, November 28, 2012 8:26 AM
>To: Logging General
>Cc: Log4NET Dev
>Subject: Re: FW: Add new FAQ entry
>
>Hi,
>
>I noticed, but didn't find the time to respond sorry :-)
>Did you see this?
>http://wiki.apache.org/logging/ManagingTheWebSite
>
>Basically you must now generate the site via mvn site and then
>copy/paste the target/site into the website svn directory
>
>hth
>Cheers
>Christian
>
>On Wed, Nov 28, 2012 at 8:20 AM, Dominik Psenner 
>wrote:
>> Hi,
>>
>> Yesterday I posted this message on log4net-dev but maybe noone noticed.
>:-)
>> Is there someone around that knows how the publishing of the log4net
>website
>> works?
>>
>> Cheers,
>> D.
>>
>>>-Original Message-
>>>From: Dominik Psenner [mailto:dpsen...@gmail.com]
>>>Sent: Tuesday, November 27, 2012 1:19 PM
>>>To: 'Log4NET Dev'
>>>Subject: Add new FAQ entry
>>>
>>>Hi,
>>>
>>>I gotta question about adding a new FAQ entry. I don't know how the build
>>>system works behind the scenes but I believe it should be enough to
>update:
>>>
>>>src\site\xdoc\release\faq.xml
>>>
>>>and commit. The website should then update itself, doesn't it?
>>>
>>>Cheers,
>>>D.
>>
>>
>
>
>
>--
>http://www.grobmeier.de
>https://www.timeandbill.de

RE: FW: Add new FAQ entry

[Dominik Psenner]

Spare time is a rare resource. :-)

I noticed a strange thing with the index.html site: parts of the index are
now missing. This affects these links below "Project Documentation":

Plugin Management
Mailing Lists
Continuous Integration
Project License
Project Team
Source Repository
About
Issue Tracking
Project Summary
Project Plugins
Dependencies

I'm sure it has something to do with:



in 'log4net\src\site\site.xml'. But where does that content come from and
how can I fix that?

>-Original Message-
>From: Christian Grobmeier [mailto:grobme...@gmail.com]
>Sent: Wednesday, November 28, 2012 8:49 AM
>To: Log4NET Dev
>Subject: Re: FW: Add new FAQ entry
>
>Cool, and thanks for updating the site!
>Good to see you are still there :-)
>
>On Wed, Nov 28, 2012 at 8:47 AM, Dominik Psenner 
>wrote:
>> Good morning Christian,
>>
>> thanks for the fast feedback. That wiki was the one I've been searching
>for.
>> :-) I'll post back if I run into more trouble. Thanks!
>>
>> Cheers,
>> D.
>>
>>>-Original Message-
>>>From: Christian Grobmeier [mailto:grobme...@gmail.com]
>>>Sent: Wednesday, November 28, 2012 8:26 AM
>>>To: Logging General
>>>Cc: Log4NET Dev
>>>Subject: Re: FW: Add new FAQ entry
>>>
>>>Hi,
>>>
>>>I noticed, but didn't find the time to respond sorry :-)
>>>Did you see this?
>>>http://wiki.apache.org/logging/ManagingTheWebSite
>>>
>>>Basically you must now generate the site via mvn site and then
>>>copy/paste the target/site into the website svn directory
>>>
>>>hth
>>>Cheers
>>>Christian
>>>
>>>On Wed, Nov 28, 2012 at 8:20 AM, Dominik Psenner 
>>>wrote:
>>>> Hi,
>>>>
>>>> Yesterday I posted this message on log4net-dev but maybe noone noticed.
>>>:-)
>>>> Is there someone around that knows how the publishing of the log4net
>>>website
>>>> works?
>>>>
>>>> Cheers,
>>>> D.
>>>>
>>>>>-Original Message-
>>>>>From: Dominik Psenner [mailto:dpsen...@gmail.com]
>>>>>Sent: Tuesday, November 27, 2012 1:19 PM
>>>>>To: 'Log4NET Dev'
>>>>>Subject: Add new FAQ entry
>>>>>
>>>>>Hi,
>>>>>
>>>>>I gotta question about adding a new FAQ entry. I don't know how the
>build
>>>>>system works behind the scenes but I believe it should be enough to
>>>update:
>>>>>
>>>>>src\site\xdoc\release\faq.xml
>>>>>
>>>>>and commit. The website should then update itself, doesn't it?
>>>>>
>>>>>Cheers,
>>>>>D.
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>http://www.grobmeier.de
>>>https://www.timeandbill.de
>>
>
>
>
>--
>http://www.grobmeier.de
>https://www.timeandbill.de

RE: FW: Add new FAQ entry

[Dominik Psenner]

>Can you check your maven version? There was a change between 2 and 3.
>Maybe its related to that.
>
>mvn --version

Apache Maven 3.0.3

I found out that the -snippet triggers mvn to generate
the projec documentation. But nonetheless mvn behaves really odd.

When I build it first I get the RAT report. When I build it again I get the
Changes and JIRA reports but the RAT report is missing. Building it once
more brings back the RAT report but JIRA and Changes are missing again.
*huh?!*

I am really afraid I could break something not obvious and this is what ist
he warning produced by maven:

[INFO] Downloading from JIRA at:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rss&pid=10690
&statusIds=5&statusIds=6&resolutionIds=1&sorter/field=created&sorter/order=D
ESC&sorter/field=priority&sorter/order=DESC&tempMax=100&reset=true&decorator
=none
[WARNING]
org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
...
Caused by: org.xml.sax.SAXParseException: The entity name must immediately
follow the '&' in the entity reference.

RE: FW: Add new FAQ entry

[Dominik Psenner]

*hm* .. using maven 2.2.1 it seems to work flawlessly. At least it does not
produce warnings. ;-) I checked the site and mostly only the dates are
changed now. *yay!*

The last problem I have now are the line endings in the generated site. I am
on windows and I suppose the svn expects \n instead of \r\n line endings?

Will the site automatically be updated once I commit the updated site?

>-Original Message-
>From: Dominik Psenner [mailto:dpsen...@gmail.com]
>Sent: Wednesday, November 28, 2012 11:07 AM
>To: 'Log4NET Dev'
>Subject: RE: FW: Add new FAQ entry
>
>>Can you check your maven version? There was a change between 2 and 3.
>>Maybe its related to that.
>>
>>mvn --version
>
>Apache Maven 3.0.3
>
>I found out that the -snippet triggers mvn to generate
>the projec documentation. But nonetheless mvn behaves really odd.
>
>When I build it first I get the RAT report. When I build it again I get the
>Changes and JIRA reports but the RAT report is missing. Building it once
>more brings back the RAT report but JIRA and Changes are missing again.
>*huh?!*
>
>I am really afraid I could break something not obvious and this is what ist
>he warning produced by maven:
>
>[INFO] Downloading from JIRA at:
>https://issues.apache.org/jira/secure/IssueNavigator.jspa?view=rss&pid=1069
>0
>&statusIds=5&statusIds=6&resolutionIds=1&sorter/field=created&sorter/order=
>D
>ESC&sorter/field=priority&sorter/order=DESC&tempMax=100&reset=true&decorato
>r
>=none
>[WARNING]
>org.apache.maven.plugin.MojoExecutionException: Failed to parse JIRA XML.
>at org.apache.maven.plugin.jira.JiraXML.parse(JiraXML.java:132)
>at org.apache.maven.plugin.jira.JiraXML.parseXML(JiraXML.java:108)
>...
>Caused by: org.xml.sax.SAXParseException: The entity name must immediately
>follow the '&' in the entity reference.

RE: FW: Add new FAQ entry

[Dominik Psenner]

>> *hm* .. using maven 2.2.1 it seems to work flawlessly. At least it does
>not
>> produce warnings. ;-) I checked the site and mostly only the dates are
>> changed now. *yay!*
>
>mvn 2 + 3 do need different things in the reporting section. Maybe we
>(you? ;-)) should look into migrating to m3 for log4net

Maybe another day. :-)

>> The last problem I have now are the line endings in the generated site. I
>am
>> on windows and I suppose the svn expects \n instead of \r\n line endings?
>
>I wrote a blog on that because it bugged me often too:
>http://www.grobmeier.de/svn-properties-client-config-05072009.html
>Common usus is native style i think

I got that one working too now. It was because I mixed mvn3 files with the
ones I generated with mvn2. But now the commit fails with:

Error: Commit failed (details follow):  
Error: Changing file  
Error:  '\log4net-site-content\log4net\log4net-1.2.11\project-reports.html'

Error:  is forbidden by the server  
Error: Access to  
Error:
'/repos/infra/!svn/txr/839889-i0ux/websites/production/loggingtest/content/l
og4net/log4net-1.2.11/project-reports.html'  
Error:  forbidden  

I have the impression that this is something someone else has to fix. :-)

Cheers,
D.

RE: FW: Add new FAQ entry

[Dominik Psenner]

That inconsistent line ending seems to be a problem with the
eol-style:native on my tortoisesvn client versioned as:

TortoiseSVN 1.7.10
Subversion 1.7.7

That svn client kept modifying half of all EOL in the files to windows
format and the other half to unix format while preparing to send the file
contents. I had to manually go through all files and convert all EOL to unix
style until the commit went through. Pretty annoying, but doable.

The website is now fresh new and up to date. Thanks for your help Christian!
If we get the chance I would definitely drink a couple of beers together.

:-)

Cheers,
Dominik

>-Original Message-
>From: Christian Grobmeier [mailto:grobme...@gmail.com]
>Sent: Wednesday, November 28, 2012 11:02 PM
>To: Log4NET Dev
>Subject: Re: FW: Add new FAQ entry
>
>> I got that one working too now. It was because I mixed mvn3 files with
>the
>> ones I generated with mvn2. But now the commit fails with:
>>
>> Error: Commit failed (details follow):
>> Error: Changing file
>> Error:  '\log4net-site-content\log4net\log4net-1.2.11\project-
>reports.html'
>>
>> Error:  is forbidden by the server
>> Error: Access to
>> Error:
>> '/repos/infra/!svn/txr/839889-
>i0ux/websites/production/loggingtest/content/l
>> og4net/log4net-1.2.11/project-reports.html'
>> Error:  forbidden
>>
>> I have the impression that this is something someone else has to fix. :-)
>
>:-)
>
>For some reason i think the link in the wiki is wrong... I found this one:
>https://svn.apache.org/repos/infra/websites/production/logging/content/
>
>it does not containt loggingtest, just logging.
>
>Could you try it with that again? At least my browser shows me correct
>content
>
>Cheers
>Christian
>
>
>> Cheers,
>> D.
>>
>
>
>
>--
>http://www.grobmeier.de
>https://www.timeandbill.de

RE: FW: Add new FAQ entry

[Dominik Psenner]

>> *hm* .. using maven 2.2.1 it seems to work flawlessly. At least it does
>not
>> produce warnings. ;-) I checked the site and mostly only the dates are
>> changed now. *yay!*
>
>[Sorry for being almost totally absent, and not only here.  Currently I
>have no idea when this will change.]

Welcome back Stefan. We haven't read you for quite a long time.

>I'm pretty sure I've been using Maven 2.2.1 when I last ran the site
>build.

This confirms that the build for now works only with mvn2.

>> The last problem I have now are the line endings in the generated site. I
>am
>> on windows and I suppose the svn expects \n instead of \r\n line endings?
>
>native would be fine if it wasn't for some broken maven plugins.  The
>generated docs will hold a mix of \r\n and \n lines - inside the same
>file.  The headers and footers are different from the content.  I
>intended to dig deep enough into maven to figure out who is wrong - but
>I read enough other lists to know it is a common problem.
>
>Back last year I ended up running Ant's fixcrl over the generated site
>before committing it (which will take ages BTW).

I believe that some source files have dos EOLs and some have unix EOLs. When
copying those together in the target files this seems to create the mixed
EOL problem. FWIW, the broken EOLs I found were always at the apache license
xml comment.

RE: Newbie - can't get anything to show in the log

[Dominik Psenner]

This is the developers list. Please ask questions in the users mailing list
[1].

Also note that there are also several answers listed in the FAQ ([2] and
[3]) that probably solve your problem.

Cheers,
D. 

[1] log4net-u...@logging.apache.org
[2]
http://logging.apache.org/log4net/release/config-examples.html#consoleappend
er
[3]
http://logging.apache.org/log4net/release/config-examples.html#rollingfileap
pender

RE: Newbie - can't get anything to show in the log

[Dominik Psenner]

>On Mon, Dec 17, 2012 at 4:08 PM, skifreak  wrote:
>> I am a developer :)
>
>:-)

*laughing* I love these kind of emails.

Re: [jira] [Commented] (LOG4NET-83) Allow flushing into file every X milliseconds

[Dominik Psenner]

I have not got the pros of "pulse events". One could already treat
some events specially, keyword: filter. Please come up with better
usecases. :-)

2013/1/11 George Chung :
> I could have sworn that there was a configuration option for
> RollingFileAppender that rolled the file based on either a fill criteria or
> a time elapsed criteria or both. Am I mistaken?
>
>
> On Fri, Jan 11, 2013 at 8:14 AM, Robert Sevcik (JIRA) 
> wrote:
>>
>>
>> [
>> https://issues.apache.org/jira/browse/LOG4NET-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551218#comment-13551218
>> ]
>>
>> Robert Sevcik commented on LOG4NET-83:
>> --
>>
>> Hi, I was thinking to submit a feature request / RFC, but this thread is
>> pretty much it.
>>
>> My idea was to inherit from ForwardingAppender to create a
>> PulsingAppender. PulsingAppender would be able to send pulse logging events
>> to the connected appenders with a configured time interval.
>>
>> A pulse would be a special kind of LoggingEvent - perhaps an inherit from
>> LoggingEvent implementing new IPulseLoggingEvent interface or just
>> containing some specific labeling data.
>>
>> Pulse aware appenders would be able to treat pulse events specially, for
>> instance carry out actions of up keep. They could silence the pulse or not
>> based on configuration perhaps.
>>
>> Pulse unaware appenders would simply log the pulse logging event.
>>
>> My motivation is the following scenario. A component writes an error log
>> very rarely, perhaps only on start-up. The error log appender does not
>> receive any event for months. There comes the day we need to clean the logs
>> up and we find the ages old error log still locked. We do not want to
>> restart the apps just to release a log. A tempting short-cut answer might be
>> to pulse-log from the application, but then you'd have to see the scale of
>> our systems and how hard it is to push a change through the development
>> cycle.
>>
>> Please let me know your thoughts. I'm willing to make a prototype. There
>> are concerns about the thread pool exhaustion, please elaborate.
>>
>> My prototype would make RollingFileAppender roll over, TextWriterAppender
>> flush, ForwardingAppenders able to stop the Pulse on Pulse. There would be
>> configuration available regarding whether to action on Pulse and whether to
>> silence the Pulse. Care would need to be taken around filtering the pulse
>> out or not, most likely with a new IFilter implementation
>>
>> Kind regards, Rob
>>
>>
>> > Allow flushing into file every X milliseconds
>> > -
>> >
>> > Key: LOG4NET-83
>> > URL: https://issues.apache.org/jira/browse/LOG4NET-83
>> > Project: Log4net
>> >  Issue Type: New Feature
>> >  Components: Appenders
>> >Affects Versions: 1.2.10
>> > Environment: All
>> >Reporter: Tal G
>> >Priority: Minor
>> > Fix For: 1.2 Maintenance Release
>> >
>> >
>> > In FileAppender you can specify either immediate flush on every message
>> > or not flushing at all.
>> > Immediate flushing reduces performance in 10% - 20%, but when flushing
>> > is skipped, then it is likely that the last few log events will not be
>> > recorded on disk when the application exits.
>> > I suggest adding a parameter that flushes to file every X millisecond.
>> > In this case you will gain most of the 10%-20% performance, and you will
>> > minimize the lost of logs when the application exits.
>>
>> --
>> 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
>
>



-- 
Dominik Psenner
## OpenPGP Key Signature #
# Key ID: B469318C   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##

Re: [jira] [Created] (LOG4NET-366) log4NET DCOM registration not working

[Dominik Psenner]

On 01/16/2013 05:39 PM, Johnson, Thomas wrote:

Anything in the event log?  Did you build log4net as 64 bit assembly or x86?

-Original Message-
From: Chirag Chandani (JIRA) [mailto:j...@apache.org]
Sent: Wednesday, January 16, 2013 6:34 AM
To: log4net-dev@logging.apache.org
Subject: [jira] [Created] (LOG4NET-366) log4NET DCOM registration not working

Chirag Chandani created LOG4NET-366:
---

  Summary: log4NET DCOM registration not working
  Key: LOG4NET-366
  URL: https://issues.apache.org/jira/browse/LOG4NET-366
  Project: Log4net
   Issue Type: Task
   Components: Builds
  Environment: OS: Windows Server 2008 R2 Application hosting server: 
IIS 7.5
 Reporter: Chirag Chandani


We have a classic ASP application running on IIS 7.5 on Windows Server 2008 R2

There is a DLL build in the code to use Log4NET logging with an ASP application.

So, In order for log4net to work on traditional ASP a DCOM object is used, which is  
"SuperMam.Logs2ASP.DLL"

The following is done for the registration:

1. REGASM with the following command:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\regasm "SuperMam.Logs2ASP.dll" 
/tlb /codebase

2. Within Component Services, A new COM+ Application is created for Logs2ASP 
(running under user NETWORK_SERVICE) and inside this application create the 
component SuperMam.Logs2ASP by choosing it from the registered components.

3. Now that the COM+ Application is configurable, The settings are changed by 
un-checking the check box for “enforce access checks for this application”

4. Then DCOMCNFG is opened on 32 bit by using mmc -32 and adding the Component 
Services add-in, to make sure he recognizes the new application.

But the problem we are facing is that Log4NET is never registered properly and 
due to which the application returns a HTTP 500

Please help in solving the situation or suggesting the error

Thanks

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

The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

You have to post within jira.

@Stefan I noticed this earlier, but shouldn't replying simply work?

[PATCH 0 of 5 ] LOG4NET-27: Hans Meiers RFA patches

[Dominik Psenner]

I pasted the patched files into a series of patches and bomb them to the 
mailing list for eassier review.

[PATCH 1 of 5] Step 1: refactoring

[Dominik Psenner]

Trivial changes to tabs and spaces, formatting etc.

diff -r b430bc3cc0f4 -r dc18d71a5304 src/Appender/RollingFileAppender.cs
--- a/src/Appender/RollingFileAppender.cs   Tue Jan 22 14:27:20 2013 +0100
+++ b/src/Appender/RollingFileAppender.cs   Tue Jan 22 14:31:05 2013 +0100
@@ -1,10 +1,10 @@
 #region Apache License
 //
-// Licensed to the Apache Software Foundation (ASF) under one or more 
+// Licensed to the Apache Software Foundation (ASF) under one or more
 // contributor license agreements. See the NOTICE file distributed with
-// this work for additional information regarding copyright ownership. 
+// this work for additional information regarding copyright ownership.
 // The ASF licenses this file to you under the Apache License, Version 2.0
-// (the "License"); you may not use this file except in compliance with 
+// (the "License"); you may not use this file except in compliance with
 // the License. You may obtain a copy of the License at
 //
 // http://www.apache.org/licenses/LICENSE-2.0
@@ -31,12 +31,12 @@
// The following sounds good, and I though it was the case, but after
// further testing on Windows I have not been able to confirm it.
 
-   /// On the Windows platform if another process has a write lock on the 
file 
+   /// On the Windows platform if another process has a write lock on the 
file
/// that is to be deleted, but allows shared read access to the file 
then the
-   /// file can be moved, but cannot be deleted. If the other process also 
allows 
-   /// shared delete access to the file then the file will be deleted once 
that 
+   /// file can be moved, but cannot be deleted. If the other process also 
allows
+   /// shared delete access to the file then the file will be deleted once 
that
/// process closes the file. If it is necessary to open the log file or 
any
-   /// of the backup files outside of this appender for either read or 
+   /// of the backup files outside of this appender for either read or
/// write access please ensure that read and delete share modes are 
enabled.
 #endif
 
@@ -68,34 +68,34 @@
/// Infinite number of backups by file size 
/// 
/// 
-   /// 
+   ///
/// 
/// 
-   /// For large or infinite numbers of backup files a  
+   /// For large or infinite numbers of backup files a 
/// greater than zero is highly recommended, otherwise all the backup 
files need
/// to be renamed each time a new backup is created.
/// 
/// 
-   /// When Date/Time based rolling is used setting  
+   /// When Date/Time based rolling is used setting 
/// to  will reduce the number of file renamings 
to few or none.
/// 
/// 
-   /// 
+   ///
/// 
/// 
/// Changing  or  without clearing
-   /// the log file directory of backup files will cause unexpected and 
unwanted side effects.  
+   /// the log file directory of backup files will cause unexpected and 
unwanted side effects.
/// 
/// 
-   /// 
+   ///
/// 
/// If Date/Time based rolling is enabled this appender will attempt to 
roll existing files
/// in the directory without a Date/Time tag based on the last write 
date of the base log file.
-   /// The appender only rolls the log file when a message is logged. If 
Date/Time based rolling 
+   /// The appender only rolls the log file when a message is logged. If 
Date/Time based rolling
/// is enabled then the appender will not roll the log file at the 
Date/Time boundary but
/// at the point when the next message is logged after the boundary has 
been crossed.
/// 
-   /// 
+   ///
/// 
/// The  extends the  and
/// has the same behavior when opening the log file.
@@ -110,7 +110,7 @@
/// When rolling a backup file necessitates deleting an older backup 
file the
/// file to be deleted is moved to a temporary name before being 
deleted.
/// 
-   /// 
+   ///
/// 
/// 
/// A maximum number of backup files when rolling on date/time 
boundaries is not supported.
@@ -123,10 +123,10 @@
/// Douglas de la Torre
/// Edward Smit
public class RollingFileAppender : FileAppender
-{
-#region Public Enums
+   {
+   #region Public Enums
 
-/// 
+   /// 
/// Style of rolling to use
/// 
/// 
@@ -231,7 +231,7 @@
/// Default constructor.
/// 
/// 
-   public RollingFileAppender() 
+   public RollingFileAppender()
{
}
 
@@ -240,9 +240,9 @@
#region Public Instance Properties
 
 #if !NET_1_0 && !CLI_1_0 && !NETCF
-/// 
+   /// 
   

[PATCH 2 of 5] Step 2: bugfix

[Dominik Psenner]

In RollOverIfDateBoundaryCrossing preserveLogFileExtension wasn't respected.

diff -r dc18d71a5304 -r 76c5f9136b8f src/Appender/RollingFileAppender.cs
--- a/src/Appender/RollingFileAppender.cs   Tue Jan 22 14:31:05 2013 +0100
+++ b/src/Appender/RollingFileAppender.cs   Tue Jan 22 14:31:24 2013 +0100
@@ -814,7 +814,7 @@
 
if 
(!(last.ToString(m_datePattern,System.Globalization.DateTimeFormatInfo.InvariantInfo).Equals(m_now.ToString(m_datePattern,
 System.Globalization.DateTimeFormatInfo.InvariantInfo
{
-   m_scheduledFilename = 
m_baseFileName + last.ToString(m_datePattern, 
System.Globalization.DateTimeFormatInfo.InvariantInfo);
+   m_scheduledFilename = 
CombinePath(m_baseFileName, last.ToString(m_datePattern, 
System.Globalization.DateTimeFormatInfo.InvariantInfo));
LogLog.Debug(declaringType, 
"Initial roll over to ["+m_scheduledFilename+"]");
RollOverTime(false);
LogLog.Debug(declaringType, 
"curSizeRollBackups after rollOver at ["+m_curSizeRollBackups+"]");