Hi,
Recent commit eliminates the need for the (Level) cast when using the
Level.setLevel method. So you don't have to change anything. :-)
Regards, Ceki
At 19:14 13.02.2002 +0100, Ceki Gülcü wrote:
>Hello,
>
>The message generated by the compiler says it all:
>
>Incompatible type for method.
> You can have the 'ObjectRenderer' act sort of like a
> 'Hashtable' and have keys for the various 'String(s)' an 'ObjectRenderer'
> exposes. For example, an 'ObjectRenderer' for 'FTPCommandInfo' might
expose
> keys like "Client IP", "Server IP", "Port", etc. that were associated with
> the corres
> Your example illustrates the problem well but, IMHO, the proposed
> solution falls far short of what's needed.
>
> It is common to let admins control the format of log files. If you
> consider HTTP servers rather than ftp servers they probably all have
> configurable formatting of log entries.
import org.apache.log4j.Priority;
/**
* This class introduces a new priority level called TRACE. TRACE has
* lower priority than DEBUG.
*/
public class TraceablePriority extends Priority {
public static final int TRACE_INT = 800;
// We assimilate TRACE to DEBUG on Syslog
private st
At 00:57 13.02.2002 +0100, Johan Känngård wrote:
>Hello all log4j (and Domino) developers,
>
>I did post a question to this list a while ago, with no response. Perhaps
>the answer was too simple, or the question too stupid. :-) Anyway, I managed
>to solve the "problem".
>
>Here are two source file
Hello,
The message generated by the compiler says it all:
Incompatible type for method. Explicit cast needed to convert
org.apache.log4j.Priority to org.apache.log4j.Level.
[javac] _creator.getRootLogger().setLevel(Level.INFO);
The solution is to change
_creator.getRo
FYI
- Sam Ruby
-- Forwarded by Sam Ruby/Raleigh/IBM on 02/13/2002
12:39 PM ---
Sam Ruby/Raleigh/IBM@IBMUS on 02/12/2002 09:04:46 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:[GUMP] Build Failure - Poi
---
FYI
>Delivered-To: [EMAIL PROTECTED]
>Reply-To: "Mark DeLaFranier" <[EMAIL PROTECTED]>
>From: "Mark DeLaFranier" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Cc: "Mark DeLaFranier" <[EMAIL PROTECTED]>
>Subject: New Feature.
>Date: Tue, 12 Feb 2002 23:41:05 -0500
>X-Mailer: Microsoft Outlook Expr
> As I follow this thread of discussion I find myself concerned that
> there is a serious issue here which needs to be correctly identified.
>
> So far as I am concerned, log4 is a really great tool for controlling
> the generation and handling the downstream distribution of log records.
> It is n
This was a major headache when I first started using Log4j, seems it's still
a headache.
Can anyone think of an easy way of adding new Priorities AND getting them to
work correctly without modifying log4j itself?
Sorry, but I'm a bit cheesed-off at the moment (not with log4j though).
Mark Dougl
We're extending the existing priority levels by adding one
below DEBUG. Since the ROOT category cannot be below DEBUG,
our new lower priority is not being honored without
modifying PropertyConfigurator.parseCategory(). Is there
any way to do what we need without having to modify log4j
code?
Thank
Burton,
Where did you get the idea that log4j is not about formatting logging
events? It most certainly is about that. Key to its design is the
separation of categories (or Loggers, if you will) on which logging
events are generated and layouts which control formatting. Generating a
logging e
As I follow this thread of discussion I find myself concerned that
there is a serious issue here which needs to be correctly identified.
So far as I am concerned, log4 is a really great tool for controlling
the generation and handling the downstream distribution of log records.
It is not, and sho
13 matches
Mail list logo
