Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: approach for defining loggers

2016-10-18 Thread 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,

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: approach for defining loggers

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: approach for defining loggers

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

DefaultRolloverStrategy max attribute and IfAccumulatedFileCount

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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.

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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,

Re: DefaultRolloverStrategy max attribute and IfAccumulatedFileCount

2016-10-18 Thread 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

Re: porting log4j2 to .NET

2016-10-18 Thread 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

Re: approach for defining loggers

2016-10-18 Thread 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