logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikael Ståldal <mikael.stal...@magine.com>
Subject Re: porting log4j2 to .NET
Date Tue, 18 Oct 2016 15:11:25 GMT
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 <boards@gmail.com> 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 <nickdu@msn.com> 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 <boards@gmail.com>
> > 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 <nickdu@msn.com> 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 <mikael.staldal@magine.com>
> > > 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 <nickdu@msn.com>
> 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 <mikael.staldal@magine.com>
> > > > 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 <nickdu@msn.com>
> > 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.staldal@magine.com
> > > > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<<<
> > http://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<http://www.magine.com/>
> > > > www.magine.com<http://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.staldal@magine.com
> > > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com<<
> > http://www.magine.com<>
> > > http://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.
> > >
> >
> >
> >
> > --
> > Matt Sicker <boards@gmail.com>
> >
>
>
>
> --
> Matt Sicker <boards@gmail.com>
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.staldal@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message