On Tue, 26 Feb 2002 [EMAIL PROTECTED] wrote:
| I use two appenders: one ConsoleAppender and the other JMSAppender
|
| log4j.rootCategory=DEBUG, A1,A2
| log4j.appender.A1=org.apache.log4j.net.JMSAppender
| .
| log4j.appender.A2=org.apache.log4j.ConsoleAppender
| .
|
| Right now, as I under
I use two appenders: one ConsoleAppender and the other JMSAppender
log4j.rootCategory=DEBUG, A1,A2
log4j.appender.A1=org.apache.log4j.net.JMSAppender
.
log4j.appender.A2=org.apache.log4j.ConsoleAppender
.
Right now, as I understand, the priority for both appender is Debug. How
can I set
> 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.
> 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
]
> Sent: Tuesday, February 12, 2002 11:00 PM
> To: Log4J Developers List
> Cc: Lance Larsen
> Subject: Re: Making object rendering more extensible
>
>
> Your example illustrates the problem well but, IMHO, the proposed
> solution falls far short of what's needed.
>
rs List
Cc: Lance Larsen
Subject: Re: Making object rendering more extensible
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 f
ogical extension.
>
> Log4j really is an excellent product. I hope that you will consider the
> changes I have suggested because I think it would help make log4j more
> extensible to meet a broader set of needs in a clean and clear fashion.
> Please let me know if there is anyt
I'll keep this short and sweet. You'll see the feature you requested in
log4j 1.3 for sure, and perhaps even in log4j 1.2. Thank you for taking the
time to explain your requirement. It was instructive and convincing.
Regards, Ceki
At 13:55 12.02.2002 -0700, Lance Larsen wrote:
>I reviewed the e-
I reviewed the e-mail I sent, and noticed a few places that I should clarify
a bit more. This may not be necessary, but in case it helps convey things a
little more clearly, here it is. Notice that if you remove my comments, this
is all part of one section that is complete (that admittedly had som
gain for an excellent
product.
-Lance Larsen
> This might be another case where Anders is a few steps ahead of me. It
> has happened in the past... so I am all ears.
> TIA, Ceki
> ps: Would it be sufficient if Appender and layouts accepted configuration
> directives for elements
Lance, Anders,
I still don't see the *practical* use of having the renderer depend on
the layout or appender. Would it be possible for you to describe a
practical case where such functionality would be useful.
This might be another case where Anders is a few steps ahead of me. It
has happened in
Lance,
You're absolutely right that this is a crippling limitation. I argued
this point with some vigor a long time ago but with zero luck. What I
would have liked to see is:
1) configurable ObjectRendererd, and
2) the ability to have per-category ObjectRenderers
This would allow us to lo
I have looked through the dev list to see if this has come up, but I haven't seen
anything so far. I have been using log4j on a few projects, and like the
configurability and extensibility it provides - very nice - thankyou for the excellent
tool.
However, there seems to be one part of the arc
14 matches
Mail list logo
