Re: porting log4j2 to .NET

[Ralph Goers]

Matt, I think you are missing the point. He wants a standard logging API that 
he can use in both .NET and Java so when the developers switch between them 
they have the same contract and functionality.

Ralph

> On Oct 18, 2016, at 6:58 AM, Matt Sicker  wrote:
> 
> Using syslog is a pretty standard way to collect logs from all sorts of
> programs and goes back decades. There has been an update to the syslog
> format in RFC 5424 which fleshes it out a bunch.
> 
> Then there are programs like Logstash and Flume which can be used in a more
> platform-agnostic manner to collect logs from different applications.
> 
> Really, when it comes down to it, the most standard way you can log
> everything regardless of programming language is to use log files or some
> sort of network appender using a standardized binary format.
> 
> On 18 October 2016 at 08:53, Nicholas Duane  wrote:
> 
>> I guess platform is vague.  Maybe I should have said language agnostic.
>> It would be nice to have a single logging architecture/design run on C/C++,
>> .NET, Java, etc.  Or at least it seems like a nice feature to me.  I would
>> assume there are many enterprises out there that have applications running
>> on different OS's and languages.  If I'm trying to pick a logging framework
>> to use and I find a popular one which is capable and runs similarly across
>> the OS's and languages then that's a big plus in my mind.
>> 
>> 
>> Thanks,
>> 
>> Nick
>> 
>> 
>> From: Mikael Ståldal 
>> Sent: Tuesday, October 18, 2016 2:52 AM
>> To: Log4J Users List
>> Subject: Re: porting log4j2 to .NET
>> 
>> Just to make things clear, Log4j is a logging framework for the JVM
>> platform, and it is agnostic to the underlying OS. It it well tested on (at
>> least) both Linux and Windows.
>> 
>> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
>> 
>>> Figured I would send this question out to the log4j side.  I have already
>>> had some email exchanges with the log4net mailing list regarding porting
>>> log4j2 to .NET.  My suggestion was that the apache logging framework be a
>>> single architecture design which is platform agnostic and then teams
>> which
>>> port to the different platforms.  It seems log4net was a port of log4j
>> and
>>> may be going off in its own direction from that initial port.  My
>> viewpoint
>>> is that's a bad idea as one of the benefits I saw was that log4net was
>>> similar to log4j2 and we're looking for logging frameworks for our
>>> enterprise.  We have applications on both Windows/.NET and Linux/Java so
>>> having a logging framework for Windows/.NET which is similar to a logging
>>> framework for Linux/Java was a big plus.
>>> 
>>> 
>>> While I have no doubt the effort to port log4j2 to .NET is considerable,
>>> it would be a port and thus I'm not spending time figuring out design and
>>> algorithms.  Would anyone want to venture a guess at what that effort
>> might
>>> be?
>>> 
>>> 
>>> Thanks,
>>> 
>>> Nick
>>> 
>> 
>> 
>> 
>> --
>> [image: MagineTV]
>> 
>> *Mikael Ståldal*
>> Senior software developer
>> 
>> *Magine TV*
>> mikael.stal...@magine.com
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<
>> http://www.magine.com>
>> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
>> http://www.magine.com/>
>> 
>> TV online with Magine TV
>> www.magine.com
>> Watch the TV you love, on any device, anywhere in Germany and Sweden and
>> find out more about our global OTT B2B solutions. Get started today.
>> 
>> 
>> 
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may not
>> copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>> 
> 
> 
> 
> -- 
> Matt Sicker 



-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: approach for defining loggers

[Nicholas Duane]

That's what I initially thought.  However, as I pointed out it has the same 
downsides as a "well known" logger.  We lose the context of what code is 
logging the call (e.g the class name which is usually used as the logger name), 
and there is no way to turn on/off a section of code from logging, in the case 
we find some errant code.  Those two are big enough issues which are keeping me 
away from using "well known" loggers.


Thanks,

Nick


From: Matt Sicker 
Sent: Monday, October 17, 2016 11:15 PM
To: Log4J Users List
Subject: Re: approach for defining loggers

What about event logging? <
https://logging.apache.org/log4j/2.x/manual/eventlogging.html>
Log4j – Log4j 2 API - Apache Log4j 
2
logging.apache.org
The EventLogger class provides a simple mechanism for logging events that occur 
in an application. While the EventLogger is useful as a way of initiating 
events that ...



This sounds pretty similar to what you're asking about. You define a map
message essentially, plus your other requirements seem to be met here.

On 17 October 2016 at 21:46, Gary Gregory  wrote:

> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane  wrote:
>
> > Sorry to revive this old thread.  However, we're in the process of adding
> > support for other "categories" of events and thus I wanted to first take
> a
> > step back and try to ensure we're not convoluting things.
> >
> >
> > There was a requirement to log a "compliance" event under certain
> > conditions.  We did not want to write our own logging framework and
> instead
> > decided to use existing off-the-shelf logging frameworks.  We have
> > applications on both Linux/Java, Windows/.NET and Windows/Java.
> Initially
> > we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> > Linux/Java.  For these logging frameworks we wrote artifacts, appenders
> > basically, to help facilitate getting these events to our system.  By the
> > way, our system will get the events centrally, possibly put them into a
> > relational database and also hand them off to another system which will
> get
> > them eventually to an HDFS backend.  We also exposed methods for creating
> > this compliance event.  The compliance event is basically a map.  We
> chose
> > a map so that the event could also be extended by the application team in
> > case they needed to add additional properties which made sense for them.
> >
> >
> > We chose to create a custom level for this "compliance" event such that
> we
> > could filter out only these events and get them into our system.  The
> > configuration example we created had our custom unix domain socket
> appender
> > added to the root logger.  It also contained a filter which filtered out
> > any events that weren't compliance events.  The level we chose for
> > "compliance" was less critical than off and more critical than fatal as
> we
> > wanted to ensure that as long as logging wasn't turned off altogether our
> > events would get logged.
> >
> >
> > I want to go over a few suggestions that were made and explain why I
> > didn't make use of those suggestions.
> >
> >
> > 1. Since our "compliance" level didn't fit within the "vernacular" of the
> > existing levels we should not define this custom level.  Instead we
> should
> > look at using markers.
> >
>
> Yes, this is a use case for markers. The level should be used to note how
> important is each compliance event.
>
>
> >
> > I am not that familiar with markers but did look into them when they were
> > suggested.  While I don't have anything against markers in general there
> > were some downsides as I saw it.
> >
> >
> > a. Markers are not available, as far as I know, in log4net so we'd still
> > have to figure out something there.
> >
>
> Indeed, we really need a port of Log4j 2 to .NET.
>
>
> >
> > b. A bigger problem, at least I thought it was a bigger problem, was that
> > there would be confusion about what level to log the event at.  I would
> > certainly not want to give an example as follows:
> >
> >
> > logger.debug(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.info(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.error(COMPLIANCE_MARKER, evnt);
> >
> >
> > ...
> >
>
> Think about: How important is this event? Are there different level of
> importance to the audience?
>
>
> >
> >
> > That just screams confusion to me.
> >
> >
> > 2. Use a dedicated logger to log all compliance events.
> >
> >
> > There were, as far as I could tell, a couple problems with this approach
> > also.
> >
> >
> > a. If everyone is using a single "well known" logger to log a specific
> > event category then I lose the logger "context" of who's logging the
> > event.  As it stands now we're copying the logger name into a property we
> > call "eventSource".
> >
>
> A practice is to use one logger per class. Another is to use 

Re: porting log4j2 to .NET

[Mikael Ståldal]

...or a standardized non-binary format (like GELF, JSON based).

On Tue, Oct 18, 2016 at 3:58 PM, Matt Sicker  wrote:

> Using syslog is a pretty standard way to collect logs from all sorts of
> programs and goes back decades. There has been an update to the syslog
> format in RFC 5424 which fleshes it out a bunch.
>
> Then there are programs like Logstash and Flume which can be used in a more
> platform-agnostic manner to collect logs from different applications.
>
> Really, when it comes down to it, the most standard way you can log
> everything regardless of programming language is to use log files or some
> sort of network appender using a standardized binary format.
>
> On 18 October 2016 at 08:53, Nicholas Duane  wrote:
>
> > I guess platform is vague.  Maybe I should have said language agnostic.
> > It would be nice to have a single logging architecture/design run on
> C/C++,
> > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> would
> > assume there are many enterprises out there that have applications
> running
> > on different OS's and languages.  If I'm trying to pick a logging
> framework
> > to use and I find a popular one which is capable and runs similarly
> across
> > the OS's and languages then that's a big plus in my mind.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal 
> > Sent: Tuesday, October 18, 2016 2:52 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Just to make things clear, Log4j is a logging framework for the JVM
> > platform, and it is agnostic to the underlying OS. It it well tested on
> (at
> > least) both Linux and Windows.
> >
> > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
> >
> > > Figured I would send this question out to the log4j side.  I have
> already
> > > had some email exchanges with the log4net mailing list regarding
> porting
> > > log4j2 to .NET.  My suggestion was that the apache logging framework
> be a
> > > single architecture design which is platform agnostic and then teams
> > which
> > > port to the different platforms.  It seems log4net was a port of log4j
> > and
> > > may be going off in its own direction from that initial port.  My
> > viewpoint
> > > is that's a bad idea as one of the benefits I saw was that log4net was
> > > similar to log4j2 and we're looking for logging frameworks for our
> > > enterprise.  We have applications on both Windows/.NET and Linux/Java
> so
> > > having a logging framework for Windows/.NET which is similar to a
> logging
> > > framework for Linux/Java was a big plus.
> > >
> > >
> > > While I have no doubt the effort to port log4j2 to .NET is
> considerable,
> > > it would be a port and thus I'm not spending time figuring out design
> and
> > > algorithms.  Would anyone want to venture a guess at what that effort
> > might
> > > be?
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.stal...@magine.com
> > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<
> > http://www.magine.com>
> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png
> ]<
> > http://www.magine.com/>
> >
> > TV online with Magine TV
> > www.magine.com
> > Watch the TV you love, on any device, anywhere in Germany and Sweden and
> > find out more about our global OTT B2B solutions. Get started today.
> >
> >
> >
> > Privileged and/or Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this message
> > (or responsible for delivery of the message to such a person), you may
> not
> > copy or deliver this message to anyone. In such case,
> > you should destroy this message and kindly notify the sender by reply
> > email.
> >
>
>
>
> --
> Matt Sicker 
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: porting log4j2 to .NET

[Nicholas Duane]

I guess platform is vague.  Maybe I should have said language agnostic.  It 
would be nice to have a single logging architecture/design run on C/C++, .NET, 
Java, etc.  Or at least it seems like a nice feature to me.  I would assume 
there are many enterprises out there that have applications running on 
different OS's and languages.  If I'm trying to pick a logging framework to use 
and I find a popular one which is capable and runs similarly across the OS's 
and languages then that's a big plus in my mind.


Thanks,

Nick


From: Mikael Ståldal 
Sent: Tuesday, October 18, 2016 2:52 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Just to make things clear, Log4j is a logging framework for the JVM
platform, and it is agnostic to the underlying OS. It it well tested on (at
least) both Linux and Windows.

On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:

> Figured I would send this question out to the log4j side.  I have already
> had some email exchanges with the log4net mailing list regarding porting
> log4j2 to .NET.  My suggestion was that the apache logging framework be a
> single architecture design which is platform agnostic and then teams which
> port to the different platforms.  It seems log4net was a port of log4j and
> may be going off in its own direction from that initial port.  My viewpoint
> is that's a bad idea as one of the benefits I saw was that log4net was
> similar to log4j2 and we're looking for logging frameworks for our
> enterprise.  We have applications on both Windows/.NET and Linux/Java so
> having a logging framework for Windows/.NET which is similar to a logging
> framework for Linux/Java was a big plus.
>
>
> While I have no doubt the effort to port log4j2 to .NET is considerable,
> it would be a port and thus I'm not spending time figuring out design and
> algorithms.  Would anyone want to venture a guess at what that effort might
> be?
>
>
> Thanks,
>
> Nick
>



--
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
www.magine.com
[https://de.magine.com/content/uploads/2016/09/magine_global_social.png]

TV online with Magine TV
www.magine.com
Watch the TV you love, on any device, anywhere in Germany and Sweden and find 
out more about our global OTT B2B solutions. Get started today.



Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: porting log4j2 to .NET

[Mikael Ståldal]

Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language
you run on the JVM (Java, Scala, Groovy, Clojure, etc).

I guess it would be nice to have similar logging framework for other
runtimes (such as .Net). However, I would not like to constrain Log4j to
only use features available on both JVM and .Net.

On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane  wrote:

> I guess platform is vague.  Maybe I should have said language agnostic.
> It would be nice to have a single logging architecture/design run on C/C++,
> .NET, Java, etc.  Or at least it seems like a nice feature to me.  I would
> assume there are many enterprises out there that have applications running
> on different OS's and languages.  If I'm trying to pick a logging framework
> to use and I find a popular one which is capable and runs similarly across
> the OS's and languages then that's a big plus in my mind.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal 
> Sent: Tuesday, October 18, 2016 2:52 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Just to make things clear, Log4j is a logging framework for the JVM
> platform, and it is agnostic to the underlying OS. It it well tested on (at
> least) both Linux and Windows.
>
> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
>
> > Figured I would send this question out to the log4j side.  I have already
> > had some email exchanges with the log4net mailing list regarding porting
> > log4j2 to .NET.  My suggestion was that the apache logging framework be a
> > single architecture design which is platform agnostic and then teams
> which
> > port to the different platforms.  It seems log4net was a port of log4j
> and
> > may be going off in its own direction from that initial port.  My
> viewpoint
> > is that's a bad idea as one of the benefits I saw was that log4net was
> > similar to log4j2 and we're looking for logging frameworks for our
> > enterprise.  We have applications on both Windows/.NET and Linux/Java so
> > having a logging framework for Windows/.NET which is similar to a logging
> > framework for Linux/Java was a big plus.
> >
> >
> > While I have no doubt the effort to port log4j2 to .NET is considerable,
> > it would be a port and thus I'm not spending time figuring out design and
> > algorithms.  Would anyone want to venture a guess at what that effort
> might
> > be?
> >
> >
> > Thanks,
> >
> > Nick
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<
> http://www.magine.com>
> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
> http://www.magine.com/>
>
> TV online with Magine TV
> www.magine.com
> Watch the TV you love, on any device, anywhere in Germany and Sweden and
> find out more about our global OTT B2B solutions. Get started today.
>
>
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: approach for defining loggers

[Ralph Goers]

The “context” of the call is only grossly captured by the logger name, and that 
is only by convention. If you really want the name of the class then you need 
the location information, which gives you the class name, method name and line 
number of the caller.

If these are “business” events why do you want to turn them off by the name of 
the logger? I would think you might want to filter out certain event types, but 
that shouldn’t be represented by the logger name.

Ralph

> On Oct 18, 2016, at 6:47 AM, Nicholas Duane  wrote:
> 
> That's what I initially thought.  However, as I pointed out it has the same 
> downsides as a "well known" logger.  We lose the context of what code is 
> logging the call (e.g the class name which is usually used as the logger 
> name), and there is no way to turn on/off a section of code from logging, in 
> the case we find some errant code.  Those two are big enough issues which are 
> keeping me away from using "well known" loggers.
> 
> 
> Thanks,
> 
> Nick
> 
> 
> From: Matt Sicker >
> Sent: Monday, October 17, 2016 11:15 PM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
> 
> What about event logging? <
> https://logging.apache.org/log4j/2.x/manual/eventlogging.html 
> >
> Log4j – Log4j 2 API - Apache Log4j 
> 2 >
> logging.apache.org 
> The EventLogger class provides a simple mechanism for logging events that 
> occur in an application. While the EventLogger is useful as a way of 
> initiating events that ...
> 
> 
> 
> This sounds pretty similar to what you're asking about. You define a map
> message essentially, plus your other requirements seem to be met here.
> 
> On 17 October 2016 at 21:46, Gary Gregory  wrote:
> 
>> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane  wrote:
>> 
>>> Sorry to revive this old thread.  However, we're in the process of adding
>>> support for other "categories" of events and thus I wanted to first take
>> a
>>> step back and try to ensure we're not convoluting things.
>>> 
>>> 
>>> There was a requirement to log a "compliance" event under certain
>>> conditions.  We did not want to write our own logging framework and
>> instead
>>> decided to use existing off-the-shelf logging frameworks.  We have
>>> applications on both Linux/Java, Windows/.NET and Windows/Java.
>> Initially
>>> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
>>> Linux/Java.  For these logging frameworks we wrote artifacts, appenders
>>> basically, to help facilitate getting these events to our system.  By the
>>> way, our system will get the events centrally, possibly put them into a
>>> relational database and also hand them off to another system which will
>> get
>>> them eventually to an HDFS backend.  We also exposed methods for creating
>>> this compliance event.  The compliance event is basically a map.  We
>> chose
>>> a map so that the event could also be extended by the application team in
>>> case they needed to add additional properties which made sense for them.
>>> 
>>> 
>>> We chose to create a custom level for this "compliance" event such that
>> we
>>> could filter out only these events and get them into our system.  The
>>> configuration example we created had our custom unix domain socket
>> appender
>>> added to the root logger.  It also contained a filter which filtered out
>>> any events that weren't compliance events.  The level we chose for
>>> "compliance" was less critical than off and more critical than fatal as
>> we
>>> wanted to ensure that as long as logging wasn't turned off altogether our
>>> events would get logged.
>>> 
>>> 
>>> I want to go over a few suggestions that were made and explain why I
>>> didn't make use of those suggestions.
>>> 
>>> 
>>> 1. Since our "compliance" level didn't fit within the "vernacular" of the
>>> existing levels we should not define this custom level.  Instead we
>> should
>>> look at using markers.
>>> 
>> 
>> Yes, this is a use case for markers. The level should be used to note how
>> important is each compliance event.
>> 
>> 
>>> 
>>> I am not that familiar with markers but did look into them when they were
>>> suggested.  While I don't have anything against markers in general there
>>> were some downsides as I saw it.
>>> 
>>> 
>>> a. Markers are not available, as far as I know, in log4net so we'd still
>>> have to figure out something there.
>>> 
>> 
>> Indeed, we really need a port of Log4j 2 to .NET.
>> 
>> 
>>> 
>>> b. A bigger problem, at least I thought it was a bigger problem, was that
>>> there would be confusion about what level to log the event at.  I would
>>> certainly not want to give an example as 

Re: porting log4j2 to .NET

[Matt Sicker]

Using syslog is a pretty standard way to collect logs from all sorts of
programs and goes back decades. There has been an update to the syslog
format in RFC 5424 which fleshes it out a bunch.

Then there are programs like Logstash and Flume which can be used in a more
platform-agnostic manner to collect logs from different applications.

Really, when it comes down to it, the most standard way you can log
everything regardless of programming language is to use log files or some
sort of network appender using a standardized binary format.

On 18 October 2016 at 08:53, Nicholas Duane  wrote:

> I guess platform is vague.  Maybe I should have said language agnostic.
> It would be nice to have a single logging architecture/design run on C/C++,
> .NET, Java, etc.  Or at least it seems like a nice feature to me.  I would
> assume there are many enterprises out there that have applications running
> on different OS's and languages.  If I'm trying to pick a logging framework
> to use and I find a popular one which is capable and runs similarly across
> the OS's and languages then that's a big plus in my mind.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal 
> Sent: Tuesday, October 18, 2016 2:52 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Just to make things clear, Log4j is a logging framework for the JVM
> platform, and it is agnostic to the underlying OS. It it well tested on (at
> least) both Linux and Windows.
>
> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
>
> > Figured I would send this question out to the log4j side.  I have already
> > had some email exchanges with the log4net mailing list regarding porting
> > log4j2 to .NET.  My suggestion was that the apache logging framework be a
> > single architecture design which is platform agnostic and then teams
> which
> > port to the different platforms.  It seems log4net was a port of log4j
> and
> > may be going off in its own direction from that initial port.  My
> viewpoint
> > is that's a bad idea as one of the benefits I saw was that log4net was
> > similar to log4j2 and we're looking for logging frameworks for our
> > enterprise.  We have applications on both Windows/.NET and Linux/Java so
> > having a logging framework for Windows/.NET which is similar to a logging
> > framework for Linux/Java was a big plus.
> >
> >
> > While I have no doubt the effort to port log4j2 to .NET is considerable,
> > it would be a port and thus I'm not spending time figuring out design and
> > algorithms.  Would anyone want to venture a guess at what that effort
> might
> > be?
> >
> >
> > Thanks,
> >
> > Nick
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<
> http://www.magine.com>
> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
> http://www.magine.com/>
>
> TV online with Magine TV
> www.magine.com
> Watch the TV you love, on any device, anywhere in Germany and Sweden and
> find out more about our global OTT B2B solutions. Get started today.
>
>
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>



-- 
Matt Sicker 

Re: porting log4j2 to .NET

[Matt Sicker]

Really, the only portable-ish way to make a common framework would be to
write them in C or Rust or something and make glue code for every runtime
out there. JVM users tend to prefer Java-native libraries over
JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
other runtimes.

On 18 October 2016 at 10:11, Mikael Ståldal 
wrote:

> In my opinion, one of the major benefits of Log4j is its comprehensive
> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
> This will automatically benefit all users of Log4j, regardless of language
> (on the JVM) and OS (that you can run the JVM on). But this does not extend
> to other runtimes (e.g. .Net).
>
> Another benefit is that your application and 3rd party frameworks/libraries
> you use can log via the same framework and you can collect the logs
> together. This does not extend to other runtimes either, since you won't
> use the same libraries.
>
> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker  wrote:
>
> > I'm saying the architecture of the code depends on the language you're
> > using. Different design patterns apply to different languages, for
> > instance. A logging framework in Java and C# might be very similar, but
> > they'd look quite different from one written entirely in Clojure or F#.
> The
> > general concept of appenders, loggers, filters, etc., would all probably
> > apply, but the APIs would probably differ a lot. This would affect plugin
> > authors more than users of the library, but the only common things I
> could
> > see happening between different languages might be a similar API in a
> > Logger class or module.
> >
> > On 18 October 2016 at 09:45, Nicholas Duane  wrote:
> >
> > > I just mentioned the config as one piece where I think it would be very
> > > useful to have similar, if not exactly the same, configs across
> > > implementations.  I also realize that it might not be possible.
> > >
> > >
> > > So are you saying that when you get to designing a logging framework
> you
> > > first have to know what language/runtime you're designing it for?  I
> > would
> > > think not.  Hopefully most, if not all, can be designed OS/runtime
> > agnostic
> > > and without having to design to a lowest common denominator.
> > >
> > >
> > > Also not sure about the OOP thing.  As far as I can tell, OOP is just a
> > > convenience thing, syntactic sugar.  I believe you can do the same in a
> > > procedural language.
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> > > 
> > > From: Matt Sicker 
> > > Sent: Tuesday, October 18, 2016 10:37 AM
> > > To: Log4J Users List
> > > Subject: Re: porting log4j2 to .NET
> > >
> > > Every programming language has its own idioms, and that even goes for
> all
> > > the various JVM languages as demonstrated by the log4j-scala API.
> Unless
> > > you mean more of an architectural thing with a similar config format,
> > then
> > > that might be more possible, but even that relies on a language being
> > > mostly OOP or mostly procedural or mostly functional or some other
> exotic
> > > thing.
> > >
> > > On 18 October 2016 at 09:23, Nicholas Duane  wrote:
> > >
> > > > I agree.  I'm also one for not coding to the lowest common
> denominator.
> > > > That's one reason we're not using a logging facade as I assume with a
> > > > facade you get only the features that are common across the set of
> > > logging
> > > > frameworks the facade supports.
> > > >
> > > >
> > > > What I'm suggesting is to come up with a design and architecture
> which
> > is
> > > > language/runtime/OS agnostic.  While it's easy for me to say that I
> > > > wouldn't be surprised if it's more difficult to achieve.  When it
> comes
> > > to
> > > > implementation I would assume the features might manifest themselves
> in
> > > > different ways across the different languages/runtimes/OS's.  For
> > > instance,
> > > > .NET has extension methods and Java doesn't.  You might decide to
> > > implement
> > > > some features in .NET using extension methods and in Java you'll have
> > to
> > > > pick a different way to implement.  Configuration might be another
> area
> > > > where there are differences among the different runtimes and thus the
> > > > implementation might be a bit different.  Maybe there's even a
> feature
> > > that
> > > > one implementation has that others don't just because there is no
> way,
> > or
> > > > no easy enough way to implement.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Nick
> > > >
> > > > 
> > > > From: Mikael Ståldal 
> > > > Sent: Tuesday, October 18, 2016 10:04 AM
> > > > To: Log4J Users List
> > > > Subject: Re: porting log4j2 to .NET
> > > >
> > > > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what
> > > language
> > > > you run on the JVM (Java, Scala, Groovy, Clojure, 

Re: porting log4j2 to .NET

[Nicholas Duane]

I agree.  I'm also one for not coding to the lowest common denominator.  That's 
one reason we're not using a logging facade as I assume with a facade you get 
only the features that are common across the set of logging frameworks the 
facade supports.


What I'm suggesting is to come up with a design and architecture which is 
language/runtime/OS agnostic.  While it's easy for me to say that I wouldn't be 
surprised if it's more difficult to achieve.  When it comes to implementation I 
would assume the features might manifest themselves in different ways across 
the different languages/runtimes/OS's.  For instance, .NET has extension 
methods and Java doesn't.  You might decide to implement some features in .NET 
using extension methods and in Java you'll have to pick a different way to 
implement.  Configuration might be another area where there are differences 
among the different runtimes and thus the implementation might be a bit 
different.  Maybe there's even a feature that one implementation has that 
others don't just because there is no way, or no easy enough way to implement.


Thanks,

Nick


From: Mikael Ståldal 
Sent: Tuesday, October 18, 2016 10:04 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language
you run on the JVM (Java, Scala, Groovy, Clojure, etc).

I guess it would be nice to have similar logging framework for other
runtimes (such as .Net). However, I would not like to constrain Log4j to
only use features available on both JVM and .Net.

On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane  wrote:

> I guess platform is vague.  Maybe I should have said language agnostic.
> It would be nice to have a single logging architecture/design run on C/C++,
> .NET, Java, etc.  Or at least it seems like a nice feature to me.  I would
> assume there are many enterprises out there that have applications running
> on different OS's and languages.  If I'm trying to pick a logging framework
> to use and I find a popular one which is capable and runs similarly across
> the OS's and languages then that's a big plus in my mind.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal 
> Sent: Tuesday, October 18, 2016 2:52 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Just to make things clear, Log4j is a logging framework for the JVM
> platform, and it is agnostic to the underlying OS. It it well tested on (at
> least) both Linux and Windows.
>
> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
>
> > Figured I would send this question out to the log4j side.  I have already
> > had some email exchanges with the log4net mailing list regarding porting
> > log4j2 to .NET.  My suggestion was that the apache logging framework be a
> > single architecture design which is platform agnostic and then teams
> which
> > port to the different platforms.  It seems log4net was a port of log4j
> and
> > may be going off in its own direction from that initial port.  My
> viewpoint
> > is that's a bad idea as one of the benefits I saw was that log4net was
> > similar to log4j2 and we're looking for logging frameworks for our
> > enterprise.  We have applications on both Windows/.NET and Linux/Java so
> > having a logging framework for Windows/.NET which is similar to a logging
> > framework for Linux/Java was a big plus.
> >
> >
> > While I have no doubt the effort to port log4j2 to .NET is considerable,
> > it would be a port and thus I'm not spending time figuring out design and
> > algorithms.  Would anyone want to venture a guess at what that effort
> might
> > be?
> >
> >
> > Thanks,
> >
> > Nick
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
> www.magine.com<
> http://www.magine.com>
> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
> http://www.magine.com/>
>
> TV online with Magine TV
> www.magine.com
> Watch the TV you love, on any device, anywhere in Germany and Sweden and
> find out more about our global OTT B2B solutions. Get started today.
>
>
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>



--
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
www.magine.com

Privileged and/or Confidential Information may 

Re: porting log4j2 to .NET

[Matt Sicker]

Every programming language has its own idioms, and that even goes for all
the various JVM languages as demonstrated by the log4j-scala API. Unless
you mean more of an architectural thing with a similar config format, then
that might be more possible, but even that relies on a language being
mostly OOP or mostly procedural or mostly functional or some other exotic
thing.

On 18 October 2016 at 09:23, Nicholas Duane  wrote:

> I agree.  I'm also one for not coding to the lowest common denominator.
> That's one reason we're not using a logging facade as I assume with a
> facade you get only the features that are common across the set of logging
> frameworks the facade supports.
>
>
> What I'm suggesting is to come up with a design and architecture which is
> language/runtime/OS agnostic.  While it's easy for me to say that I
> wouldn't be surprised if it's more difficult to achieve.  When it comes to
> implementation I would assume the features might manifest themselves in
> different ways across the different languages/runtimes/OS's.  For instance,
> .NET has extension methods and Java doesn't.  You might decide to implement
> some features in .NET using extension methods and in Java you'll have to
> pick a different way to implement.  Configuration might be another area
> where there are differences among the different runtimes and thus the
> implementation might be a bit different.  Maybe there's even a feature that
> one implementation has that others don't just because there is no way, or
> no easy enough way to implement.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal 
> Sent: Tuesday, October 18, 2016 10:04 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language
> you run on the JVM (Java, Scala, Groovy, Clojure, etc).
>
> I guess it would be nice to have similar logging framework for other
> runtimes (such as .Net). However, I would not like to constrain Log4j to
> only use features available on both JVM and .Net.
>
> On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane  wrote:
>
> > I guess platform is vague.  Maybe I should have said language agnostic.
> > It would be nice to have a single logging architecture/design run on
> C/C++,
> > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> would
> > assume there are many enterprises out there that have applications
> running
> > on different OS's and languages.  If I'm trying to pick a logging
> framework
> > to use and I find a popular one which is capable and runs similarly
> across
> > the OS's and languages then that's a big plus in my mind.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal 
> > Sent: Tuesday, October 18, 2016 2:52 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Just to make things clear, Log4j is a logging framework for the JVM
> > platform, and it is agnostic to the underlying OS. It it well tested on
> (at
> > least) both Linux and Windows.
> >
> > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
> >
> > > Figured I would send this question out to the log4j side.  I have
> already
> > > had some email exchanges with the log4net mailing list regarding
> porting
> > > log4j2 to .NET.  My suggestion was that the apache logging framework
> be a
> > > single architecture design which is platform agnostic and then teams
> > which
> > > port to the different platforms.  It seems log4net was a port of log4j
> > and
> > > may be going off in its own direction from that initial port.  My
> > viewpoint
> > > is that's a bad idea as one of the benefits I saw was that log4net was
> > > similar to log4j2 and we're looking for logging frameworks for our
> > > enterprise.  We have applications on both Windows/.NET and Linux/Java
> so
> > > having a logging framework for Windows/.NET which is similar to a
> logging
> > > framework for Linux/Java was a big plus.
> > >
> > >
> > > While I have no doubt the effort to port log4j2 to .NET is
> considerable,
> > > it would be a port and thus I'm not spending time figuring out design
> and
> > > algorithms.  Would anyone want to venture a guess at what that effort
> > might
> > > be?
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.stal...@magine.com
> > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<<
> http://www.magine.com<>
> > http://www.magine.com>
> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png
> ]<
> > http://www.magine.com/>
> >
> > TV online with Magine TV
> > www.magine.com
> > Watch the TV you love, on any device, anywhere in Germany and Sweden and
> > 

Re: porting log4j2 to .NET

[Mikael Ståldal]

In my opinion, one of the major benefits of Log4j is its comprehensive
ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
This will automatically benefit all users of Log4j, regardless of language
(on the JVM) and OS (that you can run the JVM on). But this does not extend
to other runtimes (e.g. .Net).

Another benefit is that your application and 3rd party frameworks/libraries
you use can log via the same framework and you can collect the logs
together. This does not extend to other runtimes either, since you won't
use the same libraries.

On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker  wrote:

> I'm saying the architecture of the code depends on the language you're
> using. Different design patterns apply to different languages, for
> instance. A logging framework in Java and C# might be very similar, but
> they'd look quite different from one written entirely in Clojure or F#. The
> general concept of appenders, loggers, filters, etc., would all probably
> apply, but the APIs would probably differ a lot. This would affect plugin
> authors more than users of the library, but the only common things I could
> see happening between different languages might be a similar API in a
> Logger class or module.
>
> On 18 October 2016 at 09:45, Nicholas Duane  wrote:
>
> > I just mentioned the config as one piece where I think it would be very
> > useful to have similar, if not exactly the same, configs across
> > implementations.  I also realize that it might not be possible.
> >
> >
> > So are you saying that when you get to designing a logging framework you
> > first have to know what language/runtime you're designing it for?  I
> would
> > think not.  Hopefully most, if not all, can be designed OS/runtime
> agnostic
> > and without having to design to a lowest common denominator.
> >
> >
> > Also not sure about the OOP thing.  As far as I can tell, OOP is just a
> > convenience thing, syntactic sugar.  I believe you can do the same in a
> > procedural language.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Matt Sicker 
> > Sent: Tuesday, October 18, 2016 10:37 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Every programming language has its own idioms, and that even goes for all
> > the various JVM languages as demonstrated by the log4j-scala API. Unless
> > you mean more of an architectural thing with a similar config format,
> then
> > that might be more possible, but even that relies on a language being
> > mostly OOP or mostly procedural or mostly functional or some other exotic
> > thing.
> >
> > On 18 October 2016 at 09:23, Nicholas Duane  wrote:
> >
> > > I agree.  I'm also one for not coding to the lowest common denominator.
> > > That's one reason we're not using a logging facade as I assume with a
> > > facade you get only the features that are common across the set of
> > logging
> > > frameworks the facade supports.
> > >
> > >
> > > What I'm suggesting is to come up with a design and architecture which
> is
> > > language/runtime/OS agnostic.  While it's easy for me to say that I
> > > wouldn't be surprised if it's more difficult to achieve.  When it comes
> > to
> > > implementation I would assume the features might manifest themselves in
> > > different ways across the different languages/runtimes/OS's.  For
> > instance,
> > > .NET has extension methods and Java doesn't.  You might decide to
> > implement
> > > some features in .NET using extension methods and in Java you'll have
> to
> > > pick a different way to implement.  Configuration might be another area
> > > where there are differences among the different runtimes and thus the
> > > implementation might be a bit different.  Maybe there's even a feature
> > that
> > > one implementation has that others don't just because there is no way,
> or
> > > no easy enough way to implement.
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> > > 
> > > From: Mikael Ståldal 
> > > Sent: Tuesday, October 18, 2016 10:04 AM
> > > To: Log4J Users List
> > > Subject: Re: porting log4j2 to .NET
> > >
> > > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what
> > language
> > > you run on the JVM (Java, Scala, Groovy, Clojure, etc).
> > >
> > > I guess it would be nice to have similar logging framework for other
> > > runtimes (such as .Net). However, I would not like to constrain Log4j
> to
> > > only use features available on both JVM and .Net.
> > >
> > > On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane 
> wrote:
> > >
> > > > I guess platform is vague.  Maybe I should have said language
> agnostic.
> > > > It would be nice to have a single logging architecture/design run on
> > > C/C++,
> > > > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> > > would
> > > > assume there are many 

Re: approach for defining loggers

[Nicholas Duane]

The convention is to use the class name as the logger name and we find that 
useful information.  Getting the class name, method name and line number 
dynamically I assume is costly and thus we'd probably want to just stick with 
the logger name.


We're not planning to turn off the business events by logger name, it's just a 
nice option to have in the event we have some code which is misbehaving.  We 
wouldn't have that option if we use a "well known" logger.


Thanks,

Nick


From: Ralph Goers 
Sent: Tuesday, October 18, 2016 10:01 AM
To: Log4J Users List
Subject: Re: approach for defining loggers

The “context” of the call is only grossly captured by the logger name, and that 
is only by convention. If you really want the name of the class then you need 
the location information, which gives you the class name, method name and line 
number of the caller.

If these are “business” events why do you want to turn them off by the name of 
the logger? I would think you might want to filter out certain event types, but 
that shouldn’t be represented by the logger name.

Ralph

> On Oct 18, 2016, at 6:47 AM, Nicholas Duane  wrote:
>
> That's what I initially thought.  However, as I pointed out it has the same 
> downsides as a "well known" logger.  We lose the context of what code is 
> logging the call (e.g the class name which is usually used as the logger 
> name), and there is no way to turn on/off a section of code from logging, in 
> the case we find some errant code.  Those two are big enough issues which are 
> keeping me away from using "well known" loggers.
>
>
> Thanks,
>
> Nick
>
> 
> From: Matt Sicker >
> Sent: Monday, October 17, 2016 11:15 PM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
>
> What about event logging? <
> https://logging.apache.org/log4j/2.x/manual/eventlogging.html 
> >
> Log4j – Log4j 2 API - Apache Log4j 
> 2 >
> logging.apache.org 
> The EventLogger class provides a simple mechanism for logging events that 
> occur in an application. While the EventLogger is useful as a way of 
> initiating events that ...
>
>
>
> This sounds pretty similar to what you're asking about. You define a map
> message essentially, plus your other requirements seem to be met here.
>
> On 17 October 2016 at 21:46, Gary Gregory  wrote:
>
>> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane  wrote:
>>
>>> Sorry to revive this old thread.  However, we're in the process of adding
>>> support for other "categories" of events and thus I wanted to first take
>> a
>>> step back and try to ensure we're not convoluting things.
>>>
>>>
>>> There was a requirement to log a "compliance" event under certain
>>> conditions.  We did not want to write our own logging framework and
>> instead
>>> decided to use existing off-the-shelf logging frameworks.  We have
>>> applications on both Linux/Java, Windows/.NET and Windows/Java.
>> Initially
>>> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
>>> Linux/Java.  For these logging frameworks we wrote artifacts, appenders
>>> basically, to help facilitate getting these events to our system.  By the
>>> way, our system will get the events centrally, possibly put them into a
>>> relational database and also hand them off to another system which will
>> get
>>> them eventually to an HDFS backend.  We also exposed methods for creating
>>> this compliance event.  The compliance event is basically a map.  We
>> chose
>>> a map so that the event could also be extended by the application team in
>>> case they needed to add additional properties which made sense for them.
>>>
>>>
>>> We chose to create a custom level for this "compliance" event such that
>> we
>>> could filter out only these events and get them into our system.  The
>>> configuration example we created had our custom unix domain socket
>> appender
>>> added to the root logger.  It also contained a filter which filtered out
>>> any events that weren't compliance events.  The level we chose for
>>> "compliance" was less critical than off and more critical than fatal as
>> we
>>> wanted to ensure that as long as logging wasn't turned off altogether our
>>> events would get logged.
>>>
>>>
>>> I want to go over a few suggestions that were made and explain why I
>>> didn't make use of those suggestions.
>>>
>>>
>>> 1. Since our "compliance" level didn't fit within the "vernacular" of the
>>> existing levels we should not define this custom level.  Instead we
>> should
>>> look at using markers.
>>>
>>
>> Yes, this is a use case for markers. The level should be used to note how
>> 

Re: porting log4j2 to .NET

[Nicholas Duane]

I just mentioned the config as one piece where I think it would be very useful 
to have similar, if not exactly the same, configs across implementations.  I 
also realize that it might not be possible.


So are you saying that when you get to designing a logging framework you first 
have to know what language/runtime you're designing it for?  I would think not. 
 Hopefully most, if not all, can be designed OS/runtime agnostic and without 
having to design to a lowest common denominator.


Also not sure about the OOP thing.  As far as I can tell, OOP is just a 
convenience thing, syntactic sugar.  I believe you can do the same in a 
procedural language.


Thanks,

Nick


From: Matt Sicker 
Sent: Tuesday, October 18, 2016 10:37 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Every programming language has its own idioms, and that even goes for all
the various JVM languages as demonstrated by the log4j-scala API. Unless
you mean more of an architectural thing with a similar config format, then
that might be more possible, but even that relies on a language being
mostly OOP or mostly procedural or mostly functional or some other exotic
thing.

On 18 October 2016 at 09:23, Nicholas Duane  wrote:

> I agree.  I'm also one for not coding to the lowest common denominator.
> That's one reason we're not using a logging facade as I assume with a
> facade you get only the features that are common across the set of logging
> frameworks the facade supports.
>
>
> What I'm suggesting is to come up with a design and architecture which is
> language/runtime/OS agnostic.  While it's easy for me to say that I
> wouldn't be surprised if it's more difficult to achieve.  When it comes to
> implementation I would assume the features might manifest themselves in
> different ways across the different languages/runtimes/OS's.  For instance,
> .NET has extension methods and Java doesn't.  You might decide to implement
> some features in .NET using extension methods and in Java you'll have to
> pick a different way to implement.  Configuration might be another area
> where there are differences among the different runtimes and thus the
> implementation might be a bit different.  Maybe there's even a feature that
> one implementation has that others don't just because there is no way, or
> no easy enough way to implement.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal 
> Sent: Tuesday, October 18, 2016 10:04 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language
> you run on the JVM (Java, Scala, Groovy, Clojure, etc).
>
> I guess it would be nice to have similar logging framework for other
> runtimes (such as .Net). However, I would not like to constrain Log4j to
> only use features available on both JVM and .Net.
>
> On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane  wrote:
>
> > I guess platform is vague.  Maybe I should have said language agnostic.
> > It would be nice to have a single logging architecture/design run on
> C/C++,
> > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> would
> > assume there are many enterprises out there that have applications
> running
> > on different OS's and languages.  If I'm trying to pick a logging
> framework
> > to use and I find a popular one which is capable and runs similarly
> across
> > the OS's and languages then that's a big plus in my mind.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal 
> > Sent: Tuesday, October 18, 2016 2:52 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Just to make things clear, Log4j is a logging framework for the JVM
> > platform, and it is agnostic to the underlying OS. It it well tested on
> (at
> > least) both Linux and Windows.
> >
> > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
> >
> > > Figured I would send this question out to the log4j side.  I have
> already
> > > had some email exchanges with the log4net mailing list regarding
> porting
> > > log4j2 to .NET.  My suggestion was that the apache logging framework
> be a
> > > single architecture design which is platform agnostic and then teams
> > which
> > > port to the different platforms.  It seems log4net was a port of log4j
> > and
> > > may be going off in its own direction from that initial port.  My
> > viewpoint
> > > is that's a bad idea as one of the benefits I saw was that log4net was
> > > similar to log4j2 and we're looking for logging frameworks for our
> > > enterprise.  We have applications on both Windows/.NET and Linux/Java
> so
> > > having a logging framework for Windows/.NET which is similar to a
> logging
> > > framework for Linux/Java was a big plus.
> > >
> > >
> > > While I have no 

Re: porting log4j2 to .NET

[Matt Sicker]

I'm saying the architecture of the code depends on the language you're
using. Different design patterns apply to different languages, for
instance. A logging framework in Java and C# might be very similar, but
they'd look quite different from one written entirely in Clojure or F#. The
general concept of appenders, loggers, filters, etc., would all probably
apply, but the APIs would probably differ a lot. This would affect plugin
authors more than users of the library, but the only common things I could
see happening between different languages might be a similar API in a
Logger class or module.

On 18 October 2016 at 09:45, Nicholas Duane  wrote:

> I just mentioned the config as one piece where I think it would be very
> useful to have similar, if not exactly the same, configs across
> implementations.  I also realize that it might not be possible.
>
>
> So are you saying that when you get to designing a logging framework you
> first have to know what language/runtime you're designing it for?  I would
> think not.  Hopefully most, if not all, can be designed OS/runtime agnostic
> and without having to design to a lowest common denominator.
>
>
> Also not sure about the OOP thing.  As far as I can tell, OOP is just a
> convenience thing, syntactic sugar.  I believe you can do the same in a
> procedural language.
>
>
> Thanks,
>
> Nick
>
> 
> From: Matt Sicker 
> Sent: Tuesday, October 18, 2016 10:37 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Every programming language has its own idioms, and that even goes for all
> the various JVM languages as demonstrated by the log4j-scala API. Unless
> you mean more of an architectural thing with a similar config format, then
> that might be more possible, but even that relies on a language being
> mostly OOP or mostly procedural or mostly functional or some other exotic
> thing.
>
> On 18 October 2016 at 09:23, Nicholas Duane  wrote:
>
> > I agree.  I'm also one for not coding to the lowest common denominator.
> > That's one reason we're not using a logging facade as I assume with a
> > facade you get only the features that are common across the set of
> logging
> > frameworks the facade supports.
> >
> >
> > What I'm suggesting is to come up with a design and architecture which is
> > language/runtime/OS agnostic.  While it's easy for me to say that I
> > wouldn't be surprised if it's more difficult to achieve.  When it comes
> to
> > implementation I would assume the features might manifest themselves in
> > different ways across the different languages/runtimes/OS's.  For
> instance,
> > .NET has extension methods and Java doesn't.  You might decide to
> implement
> > some features in .NET using extension methods and in Java you'll have to
> > pick a different way to implement.  Configuration might be another area
> > where there are differences among the different runtimes and thus the
> > implementation might be a bit different.  Maybe there's even a feature
> that
> > one implementation has that others don't just because there is no way, or
> > no easy enough way to implement.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal 
> > Sent: Tuesday, October 18, 2016 10:04 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what
> language
> > you run on the JVM (Java, Scala, Groovy, Clojure, etc).
> >
> > I guess it would be nice to have similar logging framework for other
> > runtimes (such as .Net). However, I would not like to constrain Log4j to
> > only use features available on both JVM and .Net.
> >
> > On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane  wrote:
> >
> > > I guess platform is vague.  Maybe I should have said language agnostic.
> > > It would be nice to have a single logging architecture/design run on
> > C/C++,
> > > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> > would
> > > assume there are many enterprises out there that have applications
> > running
> > > on different OS's and languages.  If I'm trying to pick a logging
> > framework
> > > to use and I find a popular one which is capable and runs similarly
> > across
> > > the OS's and languages then that's a big plus in my mind.
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> > > 
> > > From: Mikael Ståldal 
> > > Sent: Tuesday, October 18, 2016 2:52 AM
> > > To: Log4J Users List
> > > Subject: Re: porting log4j2 to .NET
> > >
> > > Just to make things clear, Log4j is a logging framework for the JVM
> > > platform, and it is agnostic to the underlying OS. It it well tested on
> > (at
> > > least) both Linux and Windows.
> > >
> > > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane 
> wrote:
> > >
> > > > Figured I 

Re: porting log4j2 to .NET

[Nicholas Duane]

I did look a bit into syslog.  That appeared to be the defacto standard for 
logging, though it also seems that many just write to their own log files.  The 
other constraint we had was working in a PaaS environment and thus writing to 
local disk might not be possible.  While I'm not sure whether we're going to be 
running in a PaaS environment, that's what was in the back of our minds as we 
were developing the solution.  We wrote a unix domain socket appender which we 
use to send events to a daemon we have running.  This daemon buffers events in 
memory and when the buffer is full it compresses it and sends it via http to 
one of our endpoints.


Thanks,

Nick


From: Mikael Ståldal 
Sent: Tuesday, October 18, 2016 10:06 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

...or a standardized non-binary format (like GELF, JSON based).

On Tue, Oct 18, 2016 at 3:58 PM, Matt Sicker  wrote:

> Using syslog is a pretty standard way to collect logs from all sorts of
> programs and goes back decades. There has been an update to the syslog
> format in RFC 5424 which fleshes it out a bunch.
>
> Then there are programs like Logstash and Flume which can be used in a more
> platform-agnostic manner to collect logs from different applications.
>
> Really, when it comes down to it, the most standard way you can log
> everything regardless of programming language is to use log files or some
> sort of network appender using a standardized binary format.
>
> On 18 October 2016 at 08:53, Nicholas Duane  wrote:
>
> > I guess platform is vague.  Maybe I should have said language agnostic.
> > It would be nice to have a single logging architecture/design run on
> C/C++,
> > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> would
> > assume there are many enterprises out there that have applications
> running
> > on different OS's and languages.  If I'm trying to pick a logging
> framework
> > to use and I find a popular one which is capable and runs similarly
> across
> > the OS's and languages then that's a big plus in my mind.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal 
> > Sent: Tuesday, October 18, 2016 2:52 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Just to make things clear, Log4j is a logging framework for the JVM
> > platform, and it is agnostic to the underlying OS. It it well tested on
> (at
> > least) both Linux and Windows.
> >
> > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:
> >
> > > Figured I would send this question out to the log4j side.  I have
> already
> > > had some email exchanges with the log4net mailing list regarding
> porting
> > > log4j2 to .NET.  My suggestion was that the apache logging framework
> be a
> > > single architecture design which is platform agnostic and then teams
> > which
> > > port to the different platforms.  It seems log4net was a port of log4j
> > and
> > > may be going off in its own direction from that initial port.  My
> > viewpoint
> > > is that's a bad idea as one of the benefits I saw was that log4net was
> > > similar to log4j2 and we're looking for logging frameworks for our
> > > enterprise.  We have applications on both Windows/.NET and Linux/Java
> so
> > > having a logging framework for Windows/.NET which is similar to a
> logging
> > > framework for Linux/Java was a big plus.
> > >
> > >
> > > While I have no doubt the effort to port log4j2 to .NET is
> considerable,
> > > it would be a port and thus I'm not spending time figuring out design
> and
> > > algorithms.  Would anyone want to venture a guess at what that effort
> > might
> > > be?
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.stal...@magine.com
> > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
> > www.magine.com<
> > http://www.magine.com>
> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png
> ]<
> > http://www.magine.com/>
> >
> > TV online with Magine TV
> > www.magine.com
> > Watch the TV you love, on any device, anywhere in Germany and Sweden and
> > find out more about our global OTT B2B solutions. Get started today.
> >
> >
> >
> > Privileged and/or Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this message
> > (or responsible for delivery of the message to such a person), you may
> not
> > copy or deliver this message to anyone. In such case,
> > you should destroy this message and kindly notify the sender by reply
> > email.
> >
>
>
>
> --
> Matt Sicker 
>



--
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine 

Re: porting log4j2 to .NET

[Gary Gregory]

There is also the idea of IDL from CORBA and type libraries in the MS world
where you can generate language bindings, then you are left to implement
the stubs.

Gary

On Tue, Oct 18, 2016 at 9:22 AM, Matt Sicker  wrote:

> Really, the only portable-ish way to make a common framework would be to
> write them in C or Rust or something and make glue code for every runtime
> out there. JVM users tend to prefer Java-native libraries over
> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
> other runtimes.
>
> On 18 October 2016 at 10:11, Mikael Ståldal 
> wrote:
>
> > In my opinion, one of the major benefits of Log4j is its comprehensive
> > ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd
> party.
> > This will automatically benefit all users of Log4j, regardless of
> language
> > (on the JVM) and OS (that you can run the JVM on). But this does not
> extend
> > to other runtimes (e.g. .Net).
> >
> > Another benefit is that your application and 3rd party
> frameworks/libraries
> > you use can log via the same framework and you can collect the logs
> > together. This does not extend to other runtimes either, since you won't
> > use the same libraries.
> >
> > On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker  wrote:
> >
> > > I'm saying the architecture of the code depends on the language you're
> > > using. Different design patterns apply to different languages, for
> > > instance. A logging framework in Java and C# might be very similar, but
> > > they'd look quite different from one written entirely in Clojure or F#.
> > The
> > > general concept of appenders, loggers, filters, etc., would all
> probably
> > > apply, but the APIs would probably differ a lot. This would affect
> plugin
> > > authors more than users of the library, but the only common things I
> > could
> > > see happening between different languages might be a similar API in a
> > > Logger class or module.
> > >
> > > On 18 October 2016 at 09:45, Nicholas Duane  wrote:
> > >
> > > > I just mentioned the config as one piece where I think it would be
> very
> > > > useful to have similar, if not exactly the same, configs across
> > > > implementations.  I also realize that it might not be possible.
> > > >
> > > >
> > > > So are you saying that when you get to designing a logging framework
> > you
> > > > first have to know what language/runtime you're designing it for?  I
> > > would
> > > > think not.  Hopefully most, if not all, can be designed OS/runtime
> > > agnostic
> > > > and without having to design to a lowest common denominator.
> > > >
> > > >
> > > > Also not sure about the OOP thing.  As far as I can tell, OOP is
> just a
> > > > convenience thing, syntactic sugar.  I believe you can do the same
> in a
> > > > procedural language.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Nick
> > > >
> > > > 
> > > > From: Matt Sicker 
> > > > Sent: Tuesday, October 18, 2016 10:37 AM
> > > > To: Log4J Users List
> > > > Subject: Re: porting log4j2 to .NET
> > > >
> > > > Every programming language has its own idioms, and that even goes for
> > all
> > > > the various JVM languages as demonstrated by the log4j-scala API.
> > Unless
> > > > you mean more of an architectural thing with a similar config format,
> > > then
> > > > that might be more possible, but even that relies on a language being
> > > > mostly OOP or mostly procedural or mostly functional or some other
> > exotic
> > > > thing.
> > > >
> > > > On 18 October 2016 at 09:23, Nicholas Duane  wrote:
> > > >
> > > > > I agree.  I'm also one for not coding to the lowest common
> > denominator.
> > > > > That's one reason we're not using a logging facade as I assume
> with a
> > > > > facade you get only the features that are common across the set of
> > > > logging
> > > > > frameworks the facade supports.
> > > > >
> > > > >
> > > > > What I'm suggesting is to come up with a design and architecture
> > which
> > > is
> > > > > language/runtime/OS agnostic.  While it's easy for me to say that I
> > > > > wouldn't be surprised if it's more difficult to achieve.  When it
> > comes
> > > > to
> > > > > implementation I would assume the features might manifest
> themselves
> > in
> > > > > different ways across the different languages/runtimes/OS's.  For
> > > > instance,
> > > > > .NET has extension methods and Java doesn't.  You might decide to
> > > > implement
> > > > > some features in .NET using extension methods and in Java you'll
> have
> > > to
> > > > > pick a different way to implement.  Configuration might be another
> > area
> > > > > where there are differences among the different runtimes and thus
> the
> > > > > implementation might be a bit different.  Maybe there's even a
> > feature
> > > > that
> > > > > one implementation has that others don't just because there is no
> > way,
> > > 

DefaultRolloverStrategy max attribute and IfAccumulatedFileCount

[Benjamin Jaton]

Hello,

I wonder about the relationship between the max attribute and the
IfAccumulatedFileCount.

I had wrongly assumed that if you used the Delete policy, then the max
attribute wasn't needed.
But that resulted in having a cap on the number of log files to 7 (which is
the DEFAULT_WINDOW_SIZE in DefaultRolloverStrategy)

In this example:
https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy

  

  

  


  

  

  

max is cleverly set to 100, when IfAccumulatedFileCount is set to 10.

Could we reasonably assume that max is not very useful here?

I'm thinking about setting it to the same value, or just setting max to a
very high value (100).

Thoughts?

Re: porting log4j2 to .NET

[Nicholas Duane]

I guess I don't agree.  And just to be clear, I'm not talking about trying to 
have a huge percentage, or any at all really, of single source and then glue 
code around it for the various runtimes/OS's you're targeting.


I'm not that familiar with log4j2 but I would assume you have:


* a core engine with accepts events and then runs them through some checks 
before throwing them out or sending them along their way.


* seems the major abstraction is the appender.


* some other abstractions like filters and layouts.


* configuration


* an object model such that most, if not all, can be configured programmatically


I'm sure there's some stuff I'm missing.  Still not sure why most of the design 
for this has to know what runtime/language it's targeting.


Thanks,

Nick


From: Matt Sicker 
Sent: Tuesday, October 18, 2016 12:22 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Really, the only portable-ish way to make a common framework would be to
write them in C or Rust or something and make glue code for every runtime
out there. JVM users tend to prefer Java-native libraries over
JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
other runtimes.

On 18 October 2016 at 10:11, Mikael Ståldal 
wrote:

> In my opinion, one of the major benefits of Log4j is its comprehensive
> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
> This will automatically benefit all users of Log4j, regardless of language
> (on the JVM) and OS (that you can run the JVM on). But this does not extend
> to other runtimes (e.g. .Net).
>
> Another benefit is that your application and 3rd party frameworks/libraries
> you use can log via the same framework and you can collect the logs
> together. This does not extend to other runtimes either, since you won't
> use the same libraries.
>
> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker  wrote:
>
> > I'm saying the architecture of the code depends on the language you're
> > using. Different design patterns apply to different languages, for
> > instance. A logging framework in Java and C# might be very similar, but
> > they'd look quite different from one written entirely in Clojure or F#.
> The
> > general concept of appenders, loggers, filters, etc., would all probably
> > apply, but the APIs would probably differ a lot. This would affect plugin
> > authors more than users of the library, but the only common things I
> could
> > see happening between different languages might be a similar API in a
> > Logger class or module.
> >
> > On 18 October 2016 at 09:45, Nicholas Duane  wrote:
> >
> > > I just mentioned the config as one piece where I think it would be very
> > > useful to have similar, if not exactly the same, configs across
> > > implementations.  I also realize that it might not be possible.
> > >
> > >
> > > So are you saying that when you get to designing a logging framework
> you
> > > first have to know what language/runtime you're designing it for?  I
> > would
> > > think not.  Hopefully most, if not all, can be designed OS/runtime
> > agnostic
> > > and without having to design to a lowest common denominator.
> > >
> > >
> > > Also not sure about the OOP thing.  As far as I can tell, OOP is just a
> > > convenience thing, syntactic sugar.  I believe you can do the same in a
> > > procedural language.
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> > > 
> > > From: Matt Sicker 
> > > Sent: Tuesday, October 18, 2016 10:37 AM
> > > To: Log4J Users List
> > > Subject: Re: porting log4j2 to .NET
> > >
> > > Every programming language has its own idioms, and that even goes for
> all
> > > the various JVM languages as demonstrated by the log4j-scala API.
> Unless
> > > you mean more of an architectural thing with a similar config format,
> > then
> > > that might be more possible, but even that relies on a language being
> > > mostly OOP or mostly procedural or mostly functional or some other
> exotic
> > > thing.
> > >
> > > On 18 October 2016 at 09:23, Nicholas Duane  wrote:
> > >
> > > > I agree.  I'm also one for not coding to the lowest common
> denominator.
> > > > That's one reason we're not using a logging facade as I assume with a
> > > > facade you get only the features that are common across the set of
> > > logging
> > > > frameworks the facade supports.
> > > >
> > > >
> > > > What I'm suggesting is to come up with a design and architecture
> which
> > is
> > > > language/runtime/OS agnostic.  While it's easy for me to say that I
> > > > wouldn't be surprised if it's more difficult to achieve.  When it
> comes
> > > to
> > > > implementation I would assume the features might manifest themselves
> in
> > > > different ways across the different languages/runtimes/OS's.  For
> > > instance,
> > > > .NET has extension methods and 

Re: porting log4j2 to .NET

[Nicholas Duane]

Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
the implementation will cause variations, in the config for instance.  And with 
respect to asynchronous appenders, that might even be a feature missing in some 
implementations if support for it would be too difficult.


By the way, thanks to everyone for putting up with my questions as I try to 
work though the issues I have with our implementation.


Thanks,

Nick


From: Ralph Goers 
Sent: Tuesday, October 18, 2016 4:25 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

I’ve gotten completely lost in this conversation.

The design certainly doesn’t need to know about the language, but certain 
design features have to be implementable.

For example, to use the same configuration each implementation would have to 
support the plugin concept. The Java implementation relies upon annotations to 
do this. .NET has something similar but other languages may not.  Asynchronous 
Loggers take advantage of a highly optimized concurrent queue.  Although you 
might be able to create something equivalent in other languages it might not 
scale as well.  Then again, some languages don’t support multi-threading so 
either might require all loggers to be synchronous.

Ralph

> On Oct 18, 2016, at 10:22 AM, Nicholas Duane  wrote:
>
> I guess I don't agree.  And just to be clear, I'm not talking about trying to 
> have a huge percentage, or any at all really, of single source and then glue 
> code around it for the various runtimes/OS's you're targeting.
>
>
> I'm not that familiar with log4j2 but I would assume you have:
>
>
> * a core engine with accepts events and then runs them through some checks 
> before throwing them out or sending them along their way.
>
>
> * seems the major abstraction is the appender.
>
>
> * some other abstractions like filters and layouts.
>
>
> * configuration
>
>
> * an object model such that most, if not all, can be configured 
> programmatically
>
>
> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
> design for this has to know what runtime/language it's targeting.
>
>
> Thanks,
>
> Nick
>
> 
> From: Matt Sicker >
> Sent: Tuesday, October 18, 2016 12:22 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Really, the only portable-ish way to make a common framework would be to
> write them in C or Rust or something and make glue code for every runtime
> out there. JVM users tend to prefer Java-native libraries over
> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
> other runtimes.
>
> On 18 October 2016 at 10:11, Mikael Ståldal 
> wrote:
>
>> In my opinion, one of the major benefits of Log4j is its comprehensive
>> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
>> This will automatically benefit all users of Log4j, regardless of language
>> (on the JVM) and OS (that you can run the JVM on). But this does not extend
>> to other runtimes (e.g. .Net).
>>
>> Another benefit is that your application and 3rd party frameworks/libraries
>> you use can log via the same framework and you can collect the logs
>> together. This does not extend to other runtimes either, since you won't
>> use the same libraries.
>>
>> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker  wrote:
>>
>>> I'm saying the architecture of the code depends on the language you're
>>> using. Different design patterns apply to different languages, for
>>> instance. A logging framework in Java and C# might be very similar, but
>>> they'd look quite different from one written entirely in Clojure or F#.
>> The
>>> general concept of appenders, loggers, filters, etc., would all probably
>>> apply, but the APIs would probably differ a lot. This would affect plugin
>>> authors more than users of the library, but the only common things I
>> could
>>> see happening between different languages might be a similar API in a
>>> Logger class or module.
>>>
>>> On 18 October 2016 at 09:45, Nicholas Duane  wrote:
>>>
 I just mentioned the config as one piece where I think it would be very
 useful to have similar, if not exactly the same, configs across
 implementations.  I also realize that it might not be possible.


 So are you saying that when you get to designing a logging framework
>> you
 first have to know what language/runtime you're designing it for?  I
>>> would
 think not.  Hopefully most, if not all, can be designed OS/runtime
>>> agnostic
 and without having to design to a lowest common denominator.


 Also not sure about the OOP thing.  As far as I can tell, OOP is just a
 convenience thing, syntactic sugar.  I believe you can do the same in a
 procedural language.


 Thanks,

Re: porting log4j2 to .NET

[Mikael Ståldal]

Just to make things clear, Log4j is a logging framework for the JVM
platform, and it is agnostic to the underlying OS. It it well tested on (at
least) both Linux and Windows.

On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane  wrote:

> Figured I would send this question out to the log4j side.  I have already
> had some email exchanges with the log4net mailing list regarding porting
> log4j2 to .NET.  My suggestion was that the apache logging framework be a
> single architecture design which is platform agnostic and then teams which
> port to the different platforms.  It seems log4net was a port of log4j and
> may be going off in its own direction from that initial port.  My viewpoint
> is that's a bad idea as one of the benefits I saw was that log4net was
> similar to log4j2 and we're looking for logging frameworks for our
> enterprise.  We have applications on both Windows/.NET and Linux/Java so
> having a logging framework for Windows/.NET which is similar to a logging
> framework for Linux/Java was a big plus.
>
>
> While I have no doubt the effort to port log4j2 to .NET is considerable,
> it would be a port and thus I'm not spending time figuring out design and
> algorithms.  Would anyone want to venture a guess at what that effort might
> be?
>
>
> Thanks,
>
> Nick
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: porting log4j2 to .NET

[Ralph Goers]

I feel lost because I don’t understand the concept of a code base that will run 
everywhere in any language. The run everywhere part is called “Java”. The run 
in any language part doesn’t exist as far as I know, let alone when combined 
with “run everywhere”. So I don’t know where that part of the discussion is 
coming from.

It would be possible to create implementations of the Log4j design in multiple 
languages, but we would need many more committers with skills in those various 
languages to do it.  To be sure, I would love to see that happen, but it isn’t 
possible with the set of committers who actively contribute to the logging 
project today. If you are volunteering to kick that off we won’t get in your 
way.

Ralph



> On Oct 18, 2016, at 1:53 PM, Nicholas Duane  wrote:
> 
> Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
> the implementation will cause variations, in the config for instance.  And 
> with respect to asynchronous appenders, that might even be a feature missing 
> in some implementations if support for it would be too difficult.
> 
> 
> By the way, thanks to everyone for putting up with my questions as I try to 
> work though the issues I have with our implementation.
> 
> 
> Thanks,
> 
> Nick
> 
> 
> From: Ralph Goers  >
> Sent: Tuesday, October 18, 2016 4:25 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
> 
> I’ve gotten completely lost in this conversation.
> 
> The design certainly doesn’t need to know about the language, but certain 
> design features have to be implementable.
> 
> For example, to use the same configuration each implementation would have to 
> support the plugin concept. The Java implementation relies upon annotations 
> to do this. .NET has something similar but other languages may not.  
> Asynchronous Loggers take advantage of a highly optimized concurrent queue.  
> Although you might be able to create something equivalent in other languages 
> it might not scale as well. Then again, some languages don’t support 
> multi-threading so either might require all loggers to be synchronous.
> 
> Ralph
> 
>> On Oct 18, 2016, at 10:22 AM, Nicholas Duane  wrote:
>> 
>> I guess I don't agree.  And just to be clear, I'm not talking about trying 
>> to have a huge percentage, or any at all really, of single source and then 
>> glue code around it for the various runtimes/OS's you're targeting.
>> 
>> 
>> I'm not that familiar with log4j2 but I would assume you have:
>> 
>> 
>> * a core engine with accepts events and then runs them through some checks 
>> before throwing them out or sending them along their way.
>> 
>> 
>> * seems the major abstraction is the appender.
>> 
>> 
>> * some other abstractions like filters and layouts.
>> 
>> 
>> * configuration
>> 
>> 
>> * an object model such that most, if not all, can be configured 
>> programmatically
>> 
>> 
>> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
>> design for this has to know what runtime/language it's targeting.
>> 
>> 
>> Thanks,
>> 
>> Nick
>> 
>> 
>> From: Matt Sicker  
>> >>
>> Sent: Tuesday, October 18, 2016 12:22 PM
>> To: Log4J Users List
>> Subject: Re: porting log4j2 to .NET
>> 
>> Really, the only portable-ish way to make a common framework would be to
>> write them in C or Rust or something and make glue code for every runtime
>> out there. JVM users tend to prefer Java-native libraries over
>> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
>> other runtimes.
>> 
>> On 18 October 2016 at 10:11, Mikael Ståldal > >
>> wrote:
>> 
>>> In my opinion, one of the major benefits of Log4j is its comprehensive
>>> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
>>> This will automatically benefit all users of Log4j, regardless of language
>>> (on the JVM) and OS (that you can run the JVM on). But this does not extend
>>> to other runtimes (e.g. .Net).
>>> 
>>> Another benefit is that your application and 3rd party frameworks/libraries
>>> you use can log via the same framework and you can collect the logs
>>> together. This does not extend to other runtimes either, since you won't
>>> use the same libraries.
>>> 
>>> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker >> > wrote:
>>> 
 I'm saying the architecture of the code depends on the language you're
 using. Different design patterns apply to different languages, for
 instance. A logging framework in Java and C# might be very similar, but
 they'd look quite different from one written entirely in Clojure or F#.
>>> The
 general concept of appenders, 

Re: porting log4j2 to .NET

[Nicholas Duane]

A similar analogy might be EMS.  EMS is a specification.  There is a java 
implementation, JMS.  I know TIBCO also has C/C++ and C# implementations on 
Windows.  I think the C# one is a wrapper around their C/C++ implementation.  I 
assume there is also a C/C++ implementation on Linux.


Thanks,

Nick


From: Nicholas Duane 
Sent: Tuesday, October 18, 2016 9:36 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

But I'm not suggesting a code base that will run everywhere.  As I said, I'm 
not talking about a single source code base.  What I'm suggesting is a single 
design/architecture which is then implemented across a set of runtimes/OS's.  
As opposed to what seems to be the case now where log4j is its own team with 
it's own design and log4net, I guess, was originally a port of log4j but might 
be moving in its own direction.


I suggested the same to the log4net team.  And while it could be the case that 
I could help with the log4net effort, I would not be interested in it going off 
in its own direction as I see a big benefit in having similar logging 
frameworks across Java and .NET.


Thanks,

Nick


From: Ralph Goers 
Sent: Tuesday, October 18, 2016 8:08 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

I feel lost because I don’t understand the concept of a code base that will run 
everywhere in any language. The run everywhere part is called “Java”. The run 
in any language part doesn’t exist as far as I know, let alone when combined 
with “run everywhere”. So I don’t know where that part of the discussion is 
coming from.

It would be possible to create implementations of the Log4j design in multiple 
languages, but we would need many more committers with skills in those various 
languages to do it.  To be sure, I would love to see that happen, but it isn’t 
possible with the set of committers who actively contribute to the logging 
project today. If you are volunteering to kick that off we won’t get in your 
way.

Ralph



> On Oct 18, 2016, at 1:53 PM, Nicholas Duane  wrote:
>
> Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
> the implementation will cause variations, in the config for instance.  And 
> with respect to asynchronous appenders, that might even be a feature missing 
> in some implementations if support for it would be too difficult.
>
>
> By the way, thanks to everyone for putting up with my questions as I try to 
> work though the issues I have with our implementation.
>
>
> Thanks,
>
> Nick
>
> 
> From: Ralph Goers  >
> Sent: Tuesday, October 18, 2016 4:25 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> I’ve gotten completely lost in this conversation.
>
> The design certainly doesn’t need to know about the language, but certain 
> design features have to be implementable.
>
> For example, to use the same configuration each implementation would have to 
> support the plugin concept. The Java implementation relies upon annotations 
> to do this. .NET has something similar but other languages may not.  
> Asynchronous Loggers take advantage of a highly optimized concurrent queue.  
> Although you might be able to create something equivalent in other languages 
> it might not scale as well. Then again, some languages don’t support 
> multi-threading so either might require all loggers to be synchronous.
>
> Ralph
>
>> On Oct 18, 2016, at 10:22 AM, Nicholas Duane  wrote:
>>
>> I guess I don't agree.  And just to be clear, I'm not talking about trying 
>> to have a huge percentage, or any at all really, of single source and then 
>> glue code around it for the various runtimes/OS's you're targeting.
>>
>>
>> I'm not that familiar with log4j2 but I would assume you have:
>>
>>
>> * a core engine with accepts events and then runs them through some checks 
>> before throwing them out or sending them along their way.
>>
>>
>> * seems the major abstraction is the appender.
>>
>>
>> * some other abstractions like filters and layouts.
>>
>>
>> * configuration
>>
>>
>> * an object model such that most, if not all, can be configured 
>> programmatically
>>
>>
>> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
>> design for this has to know what runtime/language it's targeting.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Matt Sicker  
>> >>
>> Sent: Tuesday, October 18, 2016 12:22 PM
>> To: Log4J Users List
>> Subject: Re: porting log4j2 to .NET
>>
>> Really, the only portable-ish way to make a common framework would be to
>> write them in C or Rust or something and make glue code for every runtime
>> out there. JVM users tend to prefer 

Re: DefaultRolloverStrategy max attribute and IfAccumulatedFileCount

[Remko Popma]

You need to explicitly set max if you want to keep more files around than the 
default. The Delete action is currently not aware of max. 

I'm not sure if it would be a good idea to change that and for example 
automatically ignore the (implicit or explicit) max value when a Delete rule is 
configured. 

Sent from my iPhone

> On 19 Oct 2016, at 3:03, Benjamin Jaton  wrote:
> 
> Hello,
> 
> I wonder about the relationship between the max attribute and the
> IfAccumulatedFileCount.
> 
> I had wrongly assumed that if you used the Delete policy, then the max
> attribute wasn't needed.
> But that resulted in having a cap on the number of log files to 7 (which is
> the DEFAULT_WINDOW_SIZE in DefaultRolloverStrategy)
> 
> In this example:
> https://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy
> 
>  
>
>  
>
>  
>
>
>  
>
>  
>
>  
> 
> max is cleverly set to 100, when IfAccumulatedFileCount is set to 10.
> 
> Could we reasonably assume that max is not very useful here?
> 
> I'm thinking about setting it to the same value, or just setting max to a
> very high value (100).
> 
> Thoughts?

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: porting log4j2 to .NET

[Nicholas Duane]

But I'm not suggesting a code base that will run everywhere.  As I said, I'm 
not talking about a single source code base.  What I'm suggesting is a single 
design/architecture which is then implemented across a set of runtimes/OS's.  
As opposed to what seems to be the case now where log4j is its own team with 
it's own design and log4net, I guess, was originally a port of log4j but might 
be moving in its own direction.


I suggested the same to the log4net team.  And while it could be the case that 
I could help with the log4net effort, I would not be interested in it going off 
in its own direction as I see a big benefit in having similar logging 
frameworks across Java and .NET.


Thanks,

Nick


From: Ralph Goers 
Sent: Tuesday, October 18, 2016 8:08 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

I feel lost because I don’t understand the concept of a code base that will run 
everywhere in any language. The run everywhere part is called “Java”. The run 
in any language part doesn’t exist as far as I know, let alone when combined 
with “run everywhere”. So I don’t know where that part of the discussion is 
coming from.

It would be possible to create implementations of the Log4j design in multiple 
languages, but we would need many more committers with skills in those various 
languages to do it.  To be sure, I would love to see that happen, but it isn’t 
possible with the set of committers who actively contribute to the logging 
project today. If you are volunteering to kick that off we won’t get in your 
way.

Ralph



> On Oct 18, 2016, at 1:53 PM, Nicholas Duane  wrote:
>
> Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
> the implementation will cause variations, in the config for instance.  And 
> with respect to asynchronous appenders, that might even be a feature missing 
> in some implementations if support for it would be too difficult.
>
>
> By the way, thanks to everyone for putting up with my questions as I try to 
> work though the issues I have with our implementation.
>
>
> Thanks,
>
> Nick
>
> 
> From: Ralph Goers  >
> Sent: Tuesday, October 18, 2016 4:25 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> I’ve gotten completely lost in this conversation.
>
> The design certainly doesn’t need to know about the language, but certain 
> design features have to be implementable.
>
> For example, to use the same configuration each implementation would have to 
> support the plugin concept. The Java implementation relies upon annotations 
> to do this. .NET has something similar but other languages may not.  
> Asynchronous Loggers take advantage of a highly optimized concurrent queue.  
> Although you might be able to create something equivalent in other languages 
> it might not scale as well. Then again, some languages don’t support 
> multi-threading so either might require all loggers to be synchronous.
>
> Ralph
>
>> On Oct 18, 2016, at 10:22 AM, Nicholas Duane  wrote:
>>
>> I guess I don't agree.  And just to be clear, I'm not talking about trying 
>> to have a huge percentage, or any at all really, of single source and then 
>> glue code around it for the various runtimes/OS's you're targeting.
>>
>>
>> I'm not that familiar with log4j2 but I would assume you have:
>>
>>
>> * a core engine with accepts events and then runs them through some checks 
>> before throwing them out or sending them along their way.
>>
>>
>> * seems the major abstraction is the appender.
>>
>>
>> * some other abstractions like filters and layouts.
>>
>>
>> * configuration
>>
>>
>> * an object model such that most, if not all, can be configured 
>> programmatically
>>
>>
>> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
>> design for this has to know what runtime/language it's targeting.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Matt Sicker  
>> >>
>> Sent: Tuesday, October 18, 2016 12:22 PM
>> To: Log4J Users List
>> Subject: Re: porting log4j2 to .NET
>>
>> Really, the only portable-ish way to make a common framework would be to
>> write them in C or Rust or something and make glue code for every runtime
>> out there. JVM users tend to prefer Java-native libraries over
>> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
>> other runtimes.
>>
>> On 18 October 2016 at 10:11, Mikael Ståldal > >
>> wrote:
>>
>>> In my opinion, one of the major benefits of Log4j is its comprehensive
>>> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
>>> This will automatically benefit all users of Log4j, regardless 

Re: approach for defining loggers

[Nicholas Duane]

I don't believe there is a severity to our compliance and business events.  I 
could be wrong.  If they had a severity it would certainly make them fit into 
the logging model more cleanly, but I just don't see it.  And I just had this 
discussion with one of my colleagues.  They were suggesting a result code for a 
business event.  However, I pointed out that you'd only need that if you 
planned on logging failed business events, which is what he was thinking.  
Would you just log the failed business event or maybe the failed business event 
and an error event?  Would a failure business event go into the business event 
store or the critical diagnostic (errors, warnings, info) store?  We might have 
systems management people monitoring the critical diagnostics store to see 
what, if any, issues are currently happening thus just logging a failed 
business event might not set of any alarms.  Though you could say that a failed 
business event it not a critical diagnostics events.  Maybe it's just a 
business failure event.  For instance, low balance.  Though I probably see a 
low balance as yet another business event, not a failure of some other business 
event.


Just in case anyone is wondering I should probably make this clear, none of the 
logging we're doing is for auditing.  We made it perfectly clear that events 
can be lost and thus you should not be using the logging frameworks and these 
events to audit.  I have a clear definition for an audit, "if you fail to audit 
then you fail the application transaction".


I'm thinking our compliance and business events would have fit nicely into the 
EventLogger.  As I mentioned, there are two issues I have with the event 
logger.  Therefore I'm thinking that maybe we provide some methods to log these 
events to the All level in an attempt to implement something similar to the 
EventLogger but do it against a private logger.  So something like this (pseudo 
code):


public class ExtensionMethods

{

public void LogEvent(Logger logger, object evnt);


or


public void LogEvent(Logger logger, String category, object evnt);

}


The other thing I'll need to make sure is that we have a way to distinguish 
between our different categories of events.  I won't use Markers as they don't 
exist on log4net and we have a "category" property anyway so I think I can use 
that.


Thanks,

Nick


From: Gary Gregory 
Sent: Monday, October 17, 2016 10:46 PM
To: Log4J Users List
Subject: Re: approach for defining loggers

On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane  wrote:

> Sorry to revive this old thread.  However, we're in the process of adding
> support for other "categories" of events and thus I wanted to first take a
> step back and try to ensure we're not convoluting things.
>
>
> There was a requirement to log a "compliance" event under certain
> conditions.  We did not want to write our own logging framework and instead
> decided to use existing off-the-shelf logging frameworks.  We have
> applications on both Linux/Java, Windows/.NET and Windows/Java.  Initially
> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> Linux/Java.  For these logging frameworks we wrote artifacts, appenders
> basically, to help facilitate getting these events to our system.  By the
> way, our system will get the events centrally, possibly put them into a
> relational database and also hand them off to another system which will get
> them eventually to an HDFS backend.  We also exposed methods for creating
> this compliance event.  The compliance event is basically a map.  We chose
> a map so that the event could also be extended by the application team in
> case they needed to add additional properties which made sense for them.
>
>
> We chose to create a custom level for this "compliance" event such that we
> could filter out only these events and get them into our system.  The
> configuration example we created had our custom unix domain socket appender
> added to the root logger.  It also contained a filter which filtered out
> any events that weren't compliance events.  The level we chose for
> "compliance" was less critical than off and more critical than fatal as we
> wanted to ensure that as long as logging wasn't turned off altogether our
> events would get logged.
>
>
> I want to go over a few suggestions that were made and explain why I
> didn't make use of those suggestions.
>
>
> 1. Since our "compliance" level didn't fit within the "vernacular" of the
> existing levels we should not define this custom level.  Instead we should
> look at using markers.
>

Yes, this is a use case for markers. The level should be used to note how
important is each compliance event.


>
> I am not that familiar with markers but did look into them when they were
> suggested.  While I don't have anything against markers in general there
> were some downsides as I saw it.
>
>
> a. Markers are not