http://babelfish.altavista.com/babelfish/urltrurl?url=http%3A%2F%2Fwww.vimeworks.com%2F%7Emauricio%2FmanualLog4J.html&lp=es_en&tt=url
Mauricio Santacruz wrote:
Hola, hace algún tiempo escribí una recopilación de la documentación de
Log4J y la puse en español, si desean mirarla y colaborar mejoran
Hi,
I want to have centralized logging in J2EE clustered environment.
Anybody have done this before ?
I am trying to understand how it can be done and issues related to it, before i
start.
what is the impact on performance ?
TIA
Shahaji
-
It doesn't make the difference...:-(
Of course, make it non-static will work technically, but conceptually
it is not correct, and performance-wise not right either...
This should be a very common problem, how does everyone handling this?
--- In [EMAIL PROTECTED], "Keith Hatton" <[EMAIL PROTECTED
I really don't think this should be the reason to make the Logger (or
its wrapper) an instance variable of each class...this should be a
fairly common problem , how do you guys handle it?
Do you have each class define and/or initialize its own Logger?
If you have a superclass and a subclass, doe
At 04/03/2003 11:09 AM, Ceki Gülcü wrote:
>
> At 09:58 AM 4/3/2003 -0600, Ebersole, Steven wrote:
> > Actually just another thought occurred to me. The MDC value is now a
> > ContextCounter instance instead of the actual value I put there. The
> > default rendering is simply to call the Object'
Unless you really want to manually process the file...
Smthg like :
cat app.log | grep INFO > cumul.log
I think you are better to use to different loggers.
Naming them should take into consideration why you want to make this
differenciation.
We push ALL the SQL's going tru' a sort of SQL-pool
Hello Haim,
I added the link as you requested.
At 05:48 PM 3/20/2003 +0200, Haim Koschitzky wrote:
Hello,
We have developed a log view and analysis application which enable web
browsing and analysis over logs.
As part of our effort to fit leading log standards we have integrated our
configuration
One approach would be to define an appender using a
org.apache.log4j.varia.LevelMatchFilter set to INFO for the cumul.log file.
This assumes you are either using an XML config, or programtically
configuring log4j (as the property file config does not recoginize filters).
The exact details of how t
At 09:58 AM 4/3/2003 -0600, you wrote:
Actually just another thought occurred to me. The MDC value is now a
ContextCounter instance instead of the actual value I put there. The
default rendering is simply to call the Object's toString() correct? So it
would seem that I would also need to add a r
Actually just another thought occurred to me. The MDC value is now a
ContextCounter instance instead of the actual value I put there. The
default rendering is simply to call the Object's toString() correct? So it
would seem that I would also need to add a renderer or override toString in
Context
This will actually work. I use Hibernate for persistence from my session
beans, I had to use this same approach to maintain the Hibernate Session
object across all nested calls.
It has worked very well there.
The only concern is that here I would not have direct control of the
ThreadLocal like I
Hola, hace algún tiempo escribí una recopilación de la documentación de
Log4J y la puse en español, si desean mirarla y colaborar mejorandola la
dirección es:
http://www.vimeworks.com/~mauricio/manualLog4J.pdf
o
http://www.vimeworks.com/~mauricio/manualLog4J.html
--
Mauricio Santacruz
Jefe de Pr
Howdy,
>-- File XMDC.java --
>import org.apache.log4j.MDC;
>
>public class XMDC {
Should this be
public class XMDC extends MDC {
...
?
I like your suggestion!
Yoav Shapira
Millennium ChemInformatics
This e-mail, including any attachments, is a confi
Howdy,
>The rub with this approach is that the MDC for a certain key might be
set
>when it should be empty.
You are of course correct. I noticed this a while ago after using MDC
for a while. However, I actually don't mind it at all as it provides
insight into the execution path at a cheaper pr
Hi Yoav,
The rub with this approach is that the MDC for a certain key might be set
when it should be empty.
At 09:22 AM 4/3/2003 -0500, you wrote:
Howdy,
My convention with MDC and NDC has been for each method to just worry
about its own logging. For example:
In SessionBeanA:
public void execu
Steven,
Your question is quite intriguing.
One solution would be to use some sort of counting. Thus, each time you set
a key in the MDC you would increment the count of that key in the MDC by
one. Each time you would "remove" the key you would decrement the count by
one but not really remove (
Howdy,
>Is making it 'final' a performance-related suggestion (i.e., does the
>compiler optimize anything if you do this), or practice-related (no
>reason to point the var at a new object)?
Both. For me it's more of the first.
This is a fairly simple thing to benchmark if you're curious about
Jacob Kjome wrote:
If you make them class static variables, it is the same as marking them
as transient. The recommended way to define a logger is probably
private static final Logger logger =
Logger.getLogger(MyClass.class.getName());
Is making it 'final' a performance-related suggestion
Yeah, that's what I was afraid of having to do.
I think I'll try just never clearing the MDC and see if that affects memory
really badly...
|-Original Message-
|From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
|Sent: Thursday, April 03, 2003 8:22 AM
|To: Log4J Users List
Howdy,
My convention with MDC and NDC has been for each method to just worry
about its own logging. For example:
In SessionBeanA:
public void executeUseCase()
// Put whatever you want into MDC
// Log entry into SessionBeanA::executeUseCase
...
// Call SessionBeanB::executeUseCaseB()
..
Hello,
In the application I'm writing I need to log 2 things.
First of all information to a log file called app.log ( ERROR, DEBUG, INFO,
... )
Secondly I have to log some information into a file cumul.log ( only INFO)
I thought to define 2 separate property files bu I think this won't work.
I
There is certain information which is thread contextual which I would like
to include into log4j's MDC to be available for logging. One of these, for
example, is the currently executing user. My architecture is such that all
requests come through a layer of stateless session EJBs. Now these EJBs
Howdy,
Who says Logger must be static? As it already your implementation will
incur a performance penalty over the log4j native implementation, as
nearly all wrappers do. Making Logger not static will only further
reduce the performance of your logging.
Yoav Shapira
Millennium ChemInformatics
Howdy,
You could reach it with grep / awk / sed on the log file ;)
The current filter concept in log4j is that you filter logging events,
not appender outputs, in order to stay appender-neutral. That's why the
method you implement from the log4j Filter declaration is
decide(LoggingEvent event) a
Perhaps something like this:
class A {
private static MyLog mLog;
protected myId;
A(){
this("A");
}
protected A(String id) {
myId = id;
init myLog with myId...
}
public void doSth(String aMsg){
mLog.debug(aMsg);
}
}
class B extends A{
B(){
super("B");
}
}
Keith
-Original Me
This was a really annoying problem. Here is what worked for me:
---
#I appended my RollingFileLogger directly to the root logger. I'm
#not sure if setting the root logger to DEBUG has any effect, but
#it seemed like the right thing to do
log4j.rootLogger=FATAL
Hi, I have a design issue related to the fact that the Logger needs
to be static. And suppose I have A and its subclass B.
I have a wrapper MyLog that wraps around Logger and a myId field of
each class, in which, the log message always print out myId of its
caller.
class A {
private static My
27 matches
Mail list logo
