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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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 <[email protected]> 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 <[email protected]> > > > > 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 <[email protected]> > > 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 <[email protected]> > > > > > 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 <[email protected]> > > > 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* > > > > > [email protected] > > > > > 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* > > > > [email protected] > > > > 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 <[email protected]> > > > > > > > > > > > -- > > Matt Sicker <[email protected]> > > > > > > -- > [image: MagineTV] > > *Mikael Ståldal* > Senior software developer > > *Magine TV* > [email protected] > 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. > -- Matt Sicker <[email protected]>
