Ralph Goers skrev:
Our requirements include enabling and disabling logging without
restarting the application. Whether it is done via the current
mechanisms or AOP doesn't really matter as this requirement doesn't
change. I realize it could be hard to implement.
I have now reached a
Ralph Goers skrev:
XLogger just provides some basic extended methods in a standardized
way. I would prefer that rather than use _log.debug you would use
XLogger.entry as it makes filtering them easier.
Let us come back to that later.
In our code we manually add entry, exit, caught,
Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev:
XLogger just provides some basic extended methods in a standardized
way. I would prefer that rather than use _log.debug you would use
XLogger.entry as it makes filtering them easier.
Let us come back to that later.
In
Ralph Goers wrote:
I'd also like to point that XLogger.enter and exit() method use the TRACE
level
whereas LogTransformer uses DEBUG. A little consistency is in oder... Either
both use TRACE or both should use DEBUG.
Obviously, I prefer TRACE for this. Logging with flow tracing
Ralph Goers wrote:
XLogger just provides some basic extended methods in a standardized
way. I would prefer that rather than use _log.debug you would use
XLogger.entry as it makes filtering them easier.
In our code we manually add entry, exit, caught, etc. to everything
except simple
Ceki Gulcu wrote:
What would be better, if it is possible, is to inject the logging
dynamically when needed and completely remove it when not, eliminating
any performance overhead at all.
Stopping and then restarting the application without the agent does exactly
that, no? Do you
Thanks,
I'm quite interested in this, but not only for entering and exiting but
eventually for other logging as well. However, I wouldn't want it in
all classes. I'd prefer to see additional configuration to define which
classes should be instrumented.
Also, once the logging is injected
Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev:
Thanks,
I'm quite interested in this, but not only for entering and exiting but
eventually for other logging as well. However, I wouldn't want it in
all classes. I'd prefer to see additional configuration to define which
classes
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev:
Does _log field refers to a logger named after the containing class? If so,
you
could enable/disable logging for each java class separately using the
configuration mechanism provided in log4j/jul/logback. In other words,
additional
Ceki Gulcu skrev:
Actually in the article I used the INFO level as it is the lowest level
printed out by j.u.l without a configuration file. I think it would be
a valid default level to keep the entry barrier as low as possible, and
then have a level keyword to the agent to override this.
Ceki Gulcu wrote:
logging for the entire class. Had you used markers, one could enable/disable
entry/exit logging without necessarily affecting logging in the rest of the
containing class. By the way, XLogger.enter() and exit() methods use the
appropriate markers.
I mentioned this as
Author: ravn
Date: Wed Oct 1 21:57:55 2008
New Revision: 1155
Added:
slf4j/trunk/slf4j-ext/src/main/java/org/slf4j/agent/AgentPremain.java
(contents, props changed)
- copied, changed from r1154,
/slf4j/trunk/slf4j-ext/src/main/java/org/slf4j/agent/AgentMain.java
Can you describe how this is intended to work? Does this inject logging
at runtime or build time?
[EMAIL PROTECTED] wrote:
Author: ravn
Date: Wed Oct 1 21:57:55 2008
New Revision: 1155
Added:
slf4j/trunk/slf4j-ext/src/main/java/org/slf4j/agent/AgentPremain.java
(contents, props
Ralph Goers skrev:
Can you describe how this is intended to work? Does this inject logging
at runtime or build time?
Naturally.
It will inject logging statements at runtime (specifically class load
time) in all classes (which I am reconsidering) except some which are
blacklisted.
14 matches
Mail list logo
