We currently use:
FATAL - logged. Failure to correctly handle an exception and recover is a
breach of our standards, the application should not fail unless something it
is dependent on (e.g. database) fails first. If there is some critical
system error (e.g. server runs out of disc space) then
Mikael Ståldal skrev:
then set the logger levels for both hierarchies to DEBUG, and write
yourself a simple custom Filter implementation that accepts/denies
events based on your logic, and attach a separate configured instance
of that filter to each of the appenders (accepting/denying as the
Hi,
My application is such that, at start-up,the first component brings up a new
JVM containing the other components.
I have a log4j file having one Console and one File appenders attached to
the root logger. The same file is being configured by both the JVMs at their
startup.
The problem is
Hello,
I'm trying to figure out what things I need to place in my Tab
identifier field to filter out my applications. I'm using log4j v
1.2.13 and chainsaw v2. I have two applications running on the same
server and both are using a socketHubAppender on different ports.
I don't have any
Two things:
1. To get every socketappender connection to display in its own tab in
Chainsaw, use PROP.log4j.remoteSourceInfo as the tab identifier (note
the log4j. in front of the property name - log4j. isn't some special
property name, that's just the name of the property).
2. The
Thanks Scott that was very helpful (and fast).
Am I missing the reference to what Prop keyNames are available? It
would be nice to know what is available (who knows maybe I'll find
something i didn't know i couldn't live without). Even if it's just a
matter of looking at the right
Sorry Scott I had not tried your instructions before I replied last
time.
I can get PROP.log4j.remoteSourceInfo to show up in my tab identifier
but PROP.application does not seem to work (which to be honest is much
closer to what I want). I've seen that there is an issue with the
Properties in Chainsaw are any name/value pair -property- associated
with a received event - they are displayed in their own column in the
event table.
MDC entries show up as properties in Chainsaw.
Any arbitrary name/value pair can be added as properties to events, and
MDC is one way to get
SocketHubAppender doesn't have the 'application' property support built
into the appender like 1.2.15 socketappender does, so to use the
application property with sockethubappender, you'd have to:
- use log4j 1.2.15 on the appender side
- also include the receivers companion in the classpath
-
I'm sure you get this a lot but after reading quite a few posts I am
still kind of confused:
The lineage between the 1.3 and 1.2 branches is very hazy. From what
i can tell 1.3 is essentially dead and that 1.2 is the recommended
version to use.
As for chainsaw, should I be using the v2
log4j 1.3 is abandoned - the useful bits were (mostly) backported to
log4j 1.2.15 with a few 'companion' downloads providing the non-core
functionality added to 1.3.
There are a few caveats:
- Chainsaw V2 trunk (built against log4j 1.2.15) has not yet been
released. Once it is released,
11 matches
Mail list logo
