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.
> On Oct 18, 2016, at 6:58 AM, Matt Sicker wrote:
> Using syslog
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,
...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
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
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
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
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
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
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
What I'm suggesting is to come up with a
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
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
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
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
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
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
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
On Tue, Oct 18, 2016 at 9:22 AM, Matt Sicker wrote:
> Really, the only portable-ish way to make a common
I wonder about the relationship between the max attribute and the
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
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
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
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.
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
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
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.
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
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
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
Mail list logo