Larry Young wrote on 08/15/2003 03:12 AM:
Paul,
Yes, actually I had already gone down that road as one of my
first solutions before I posted my original message. However, when I
considered that option, I was appending the logging type, which was a
problem when trying to specify package
> Yes, actually I had already gone down that road as one of my first
> solutions before I posted my original message. However, when I considered
> that option, I was appending the logging type, which was a problem when
> trying to specify packages instead of individual classes. But yo
Paul,
Yes, actually I had already gone down that road as one of my first
solutions before I posted my original message. However, when I considered
that option, I was appending the logging type, which was a problem when
trying to specify packages instead of individual classes. But your
On Fri, 2003-08-15 at 10:52, Larry Young wrote:
> Paul,
>
> Yes, I need to be able to specify which class may display which
> set of discreet types. For example, I might have "com.*" allowed to
> display ERROR, but then override that for "com.xyz.MyClass" to display only
> TIMING, "c
Paul,
Yes, I need to be able to specify which class may display which
set of discreet types. For example, I might have "com.*" allowed to
display ERROR, but then override that for "com.xyz.MyClass" to display only
TIMING, "com.abc.def.*" to display METHOD_TRACE & TIMING, and
"com.abc
On Fri, 2003-08-15 at 07:49, Larry Young wrote:
> Ceki,
>
> That's an interesting way of looking at logger types! But how
> would that allow me to enable/disable log messages for a particular
> class? One of the features I need is the ability to specify that a
> particular class shou
Ceki,
That's an interesting way of looking at logger types! But how
would that allow me to enable/disable log messages for a particular
class? One of the features I need is the ability to specify that a
particular class should display a particular type of log message (or
possibly mor
At 11:10 PM 8/14/2003 +0200, Ceki Gülcü wrote:
If it can run, it can also walk!
I think the existing system can be made to closely simulate the behavior
you describe.
Here is how:
- Set the root logger to the level OFF.
- Name your loggers as "fatal", "error", "timing", "CodeBlock",
"Control
If it can run, it can also walk!
I think the existing system can be made to closely simulate the behavior
you describe.
Here is how:
- Set the root logger to the level OFF.
- Name your loggers as "fatal", "error", "timing", "CodeBlock",
"ControlPoint", "DBAccess", "Info", etc. Set their level
Paul,
Thanks for the response. Let me repeat back to you what I think
you are saying to be sure I understand.
Basically you are using MDC (I don't think NDC would be quite
right, and not sure what Properties are in this context) to add a
"user-specified" attribute to each logg
Hi Larry,
This is where you would probably delve into the MDC/NDC/Properties
usage.
At each 'type' point/location in code I would add a MDC/NDC/Property
(whatever works best) at the point, and remove it afterwards where
appropriate. The log events generated between these places would then
have
Hello,
I'm looking at creating a logging package for our applications
(web & non-web). The reason for yet-another-logger is that I want
discreet logging types, not hierarchical levels. I've built this kind of a
package before for previous projects, and ended up building the whole thi
12 matches
Mail list logo
